For pointers: don't try to set master->valuator fields if there is no master.
For keyboards: check if device is valid before trying to access the fields in
miPointerGetScreen (btw. this disables DGA events for floating keyboards).
Also stop the hideous number of ErrorFs if we request the paired device for a
floating dev.
XkbRemoveResourceClient wants to access xkbInfo if it exists, so make
sure we NULL it after freeing it. It doesn't make much sense to move
the RemoveResourceClient call first, as there's not much point in
notifying clients while we're shutting the server down anyway.
Subject: [PATCH] fix some performance gaps in Xace
The XaceHook function is used in several hotpaths.
The problem with it (performance wise) is twofold:
* The XaceHook function has a big switch() statement for the hook number in it
* The XaceHook function uses varargs to reassemble the final dispatch arguments again
Both are expensive operations... for something that is known at compile time
This patch turns the hotpath XaceHook call into a direct call to avoid
the switch and varargs; this gives me over 10% performance gain
on the x11perf benchmark.
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.
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 5ee409794e)
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.
Floating devices get sprites, but still aren't spriteOwners. This prevents
them from getting rendered, and also stops segfaulting.
(not really solving the problems with keyboards though)
Set isMaster for VCP/VCK.
Init sprites for master pointer devices.
Pair master kbds with master pointers (1:1 pairing!).
Attach other devices to VCP/VCK.
For now, we don't allow attaching slaves to other slaves, and we don't allow
pairing slaves with other slaves.
Pairing is for master keyboard->master pointer only.
Attaching is for slave device->master device only.
We re-pair them with the VCP, not a real device! If we would do otherwise,
somebody may change our keyboard focus and thus get us typing where we don't
want to type.
If the pairing client is not set, then the pairing is initiated internally
(e.g. when a new keyboard device is configured). In this case we _must_ pair
regardless of who is the pairing client.
In some cases a button press may activate a passive core grab. If the client
owning the passive grab already has a core grab on another device, don't
actually activate it. Otherwise the client gets two simultaneous passive
core grabs, and may never ungrab the device again (only if the other grab uses
GrabModeSync).
Reproducable: fire up gnome-session, open up gnome-terminal. Click with the
ClientPointer onto the window decoration, then click with another pointer onto
an application icon in the panel. Drag the icon out, release the button and
voila - you just lost your second mouse.
This is a half-assed attempt at getting rid of some enter-leave problems. When
a grab is activated, the events didn't get sent before, leading to interesting
results. This commit papers over it but doesn't actually fix it properly. The
whole enter/leave (focusin/out) structure needs to be ripped out and changed
for multiple devices.
Unfortunately, more information is needed to properly label the device.
This will come from the configuration file, the hotplug messages, etc.
It will either have to be passed into this function,
or this hook moved down into the callers.
* 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.
Let the drivers only generate XI events and put those into the event queue.
When processing events, generate core events as needed. This fixes a number of
problems with XKB and the DIX in general.
The previous approach was to put core events and XI events as separate events
into the event queue. When being processed, the server had no knowledge of
them coming from the same device state change. Anything that would then change
the state of the device accordingly was in danger of changing it twice,
leading to some funny (i.e. not funny at all) results.
Emulating core events while processing XI events fixes this, there is only one
path that actually changes the device state now. Although we have to be
careful when replaying events from synced devices, otherwise we may lose
events.
Note: XI has precedence over core for passive grabs, but core events are
delivered to the client first.
This removes the wrapping added in 340911d724
We need it unconditionally in a few places, and the rest checked for NULL and
then set it to VCK anyway. So, fixing up all callers to appreciate the defined
return value.
GenericEvents can't be parsed to keyButtonPointer, and there's no guarantee
that it has a time field anyway. PlayReleasedEvent needs to store the millis
when we know it (core events, XI event) and just re-use them for GenericEvents.
Yes, this is a hack. But it looks like the time has zero significance 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.
EnableDevices is (amongst others )called after a VT switch. We must not create
a new sprite or re-pair the device, otherwise we lose the input device setup
that we had before the VT switch.
This requires the devices to be in exactly the same order as before
the VT switch. Removing a device while on a different VT is probably a bad
idea.
The device state needs to be changed while processing the XI event. Core
events are always processed after XI, so by then the device is already set up
properly. However, we now rely on DeviceButtonMotionMask to be equal to
ButtonMotionMask. It already is, but stick a big fat warning in so nobody
attempts to change it.
This commit disables XKB for the VCK, thus essentially for all devices.
Temporarily anyway.
Add keyc->postdown, which represents the key state as of the last mieqEnqueue
call, and use it when we need to know the posted state, instead of the
processed state (keyc->down). Add small functions to getevents.c to query and
modify key state in postdown and use them all through, eliminating previously
broken uses.