GitLab

It doesn't link against cfb, so don't conditionalize its build against cfb.

In a multihead setup, if only the first screen can be
initialized, but the second screen is mentioned first in the
ServerLayout section, the xf86InitOrigins() function will crash
because the screen referred to in the e.g. "RightOf" part is
non-existent.

Pass all VBE modes back up to the driver, on the assumption that it
knows how to filter modes intelligently.

The transformation between fbdev and xfree86 mode timings needs to be
invertible, otherwise Xen and other framebuffers that don't have real
pixel clocks won't initialize.

The kernel will always upconvert to ExplorerPS/2 for all readers of
/dev/input/mice, so don't waste time on startup trying to figure
that out.

Due to RANDR 1.2, xf86findOptionValue and xf86nameCompare are now ABI.
Make sure they're exported from the server.

If we inherited a signal mask from the parent process that ignores SIGUSR1,
then we will send SIGUSR1 to the parent to indicate when we're ready to
accept connections.  Unfortunately, we send this notification way too
early, right after creating the sockets rather than just before entering
the main loop.

Move it to just before Dispatch() so we're not lying quite so much.

The extension is entirely DIX-level, no new DDX changes needed.

The smart scheduler itimer currently always fires after each request
(which in turn causes the CPU to wake out of idle, burning precious
power). Rather than doing this, just stop the timer before going into
the select() portion of the WaitFor loop. It's a cheap system call, and
it will only get called if there's no more commands batched up from the
active fd.

This change also allows some of the functions to be simplified;
setitimer() will only fail if it's passed invalid data, and we don't do
that... so make it void and remove all the conditional code that deals
with failure.

The change also allows us to remove a few variables that were used for
housekeeping between the signal handler and the main loop.
Signed-off-by: Keith Packard <keithp@koto.keithp.com>

This makes the root visual a GLX capable visual again and adds a GLX visual
for the COMPOSITE ARGB visual cleanly (as opposed to the hack we had before).

This changes the module initalization order so that the GLX module initializes
after COMPOSITE.  The reason for this change is to be able to initialize a
GLX visual config for the COMPOSITE ARGB visual.

Call ProcessOtherEvents first, then for all keyboard devices let them be
wrapped by XKB. This way all XI events will go through XKB.

Note that the VCK is still not wrapped, so core events will bypass XKB.

(cherry picked from commit d627061b)

Cope with Xi and pointer events in the (now increasingly misnamed)
XkbProcessKeyboardEvent.  If it's the wrong type, call through the wrapping
chain to get out; else, process it.

Don't get XkbUpdateIndicators to update the indicators on all our devices: we
already deal with that ourselves.
Add exevents.h include to get more (proto)types.

Instead of hardcoding CoreProcessPointerEvent, actually try to unwrap properly
and then call the unwrapped processInputProc. Seems to be a better idea,
especially since it makes stuff actually work...
(cherry picked from commit 8f9bf927)

This is hopefully better than hardcodey calling CoreProcessPointerEvent.
(cherry picked from commit 32d0440c)

(cherry picked from commit 8840829a)

FixKeyState needs to be able to handle XI events, otherwise we get "impossible
keyboard events" on server zaps and other special key combos.
(cherry picked from commit 5ee40979)

XI events can now take the same processing paths as core events, and should do
the correct state changes etc.

There's some cases where XKB will use KeyPress as type for an event to be
delivered to the client. Stuck warnings in, not sure what the correct solution
is yet.

(cherry picked from commit 6334d4e7 with some
 additional compile fixes and non-MPX adaptations)

using a hardcoded ProcessKeyboardEvent. Otherwise we lose the ability to
process DeviceKeyEvents after the first key press.

This should be the correct fix now.
(cherry picked from commit 4d5df14f)

Using a global array for action filters is bad. If two keyboard hit a modifier
at the same time, releaseing the first one will deactivate the filter and
thus the second keyboard can never release the modifier again.
(cherry picked from commit bfe6b4d2)

YOU PRESSED A KEY
AND AGAIN
YOU RELEASED A KEY
AND AGAIN
YOU PRESSED A KEY
AND AGAIN

... not so much.

Add the device private index, given we use that in a macro here, and also the
prototype for xkbUnwrapProc, since that's also useful.

Make sure we have all the types we need to use this header.

Don't build XF86Misc or XF86Vidmode in hw/xfree86/dixmod when it's been
explicitly disabled in configure, or we don't have the proto modules
installed.

Restore the CompositeGlyphs -> ps->Glyphs -> miGlyphs callchain to allow acceleration architectures to wrap above miGlyphs.

This is required by a buggy version of the openssl/sha.h header
which is distributed with Fedora 7.

When we're building with --enable-debug, don't emit an ErrorF every time a
function gets called.

Fix the botched previous key_is_down test, which would give false positives.
Also move key_autorepeats to a separate inline function.

Based on patch by Hong Liu <hong.liu@intel.com>.