These hints allow an acceleration architecture to optimize allocation of certain
types of pixmaps, such as pixmaps that will serve as backing pixmaps for
redirected windows.
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 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>
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 6334d4e7be 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 4d5df14f2c)
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 bfe6b4d2d9)
the hook - the hook only needs the Atom to control access to the selection
object. Upgraded the SelectionCallback to take a client argument and
additional type codes so that it can be used for redirection.
* configure.ac,include/dix-config.h.in: define the XEPHYR_DRI macro.
define it when --enable-xephyr and --enable-dri are both turned on.
* hw/kdrive/ephyr/XF86dri.c: copy this from mesa source to enable
Xephyr to talk DRI protocol the host X. In mesa, this is used by libGL.so to
talk DRI protocol with the server.
* hw/kdrive/ephyr/ephyr.c: finally initialise the DRI extension
in the ephyrInitScreen() function.
* hw/kdrive/ephyr/ephyrdri.c,ephyrdriext.c: safeguard the compilation
using the XEPHYR_DRI macro.
* dix/events.c, include/dix.h:
(UpdateSpriteForScreen): added this to update the mouse sprite context
when we switch from a pScreen to another.
* mi/mipointer.c:
(miPointerWarpCursor): as we are switching to a new pScreen,
don't forget to update the mouse sprite context.
Removes "LookupKeyboardDevice" and "LookupPointerDevice" in favor of
inputInfo.keyboard and inputInfo.pointer, respectively; all use cases
are non-XI compliant anyway.
This was an attempt to avoid scratch gc creation and validation for paintwin
because that was expensive. This is not the case in current servers, and the
danger of failure to implement it correctly (as seen in all previous
implementations) is high enough to justify removing it. No performance
difference detected with x11perf -create -move -resize -circulate on Xvfb.
Leave the screen hooks for PaintWindow* in for now to avoid ABI change.
