XkbFinishDeviceInit does the following:
xkbi->kbdProc= pXDev->kbdfeed->CtrlProc;
pXDev->kbdfeed->CtrlProc= XkbDDXKeybdCtrlProc;
If we directly copy the device classes for the VCK, pXDev->kbdfeed->CtrlProc
at the time of copying is still XbkDDXKeybdCtrlProc. So at some point
XkbDDXKeybdCtrlProc is called, and calls itself, and calls itself, and...
Setting the device's classes to NULL seems to fix things. The memory isn't
lost, it gets stored into the devPrivates and freed at device closing time.
To recap: the original XC-SECURITY extension disallowed background "None" if
the window was untrusted. XACE 1.0 preserved this check as a hook function.
XACE pre-2.0 removed the hook and first abolished background "None entirely,
then restored it as a global on/off switch in response to Bug #13683.
Now it's back to being per-window, via a flag instead of a hook function.
Before we enable the device through the driver, we size it up and make sure
that the events in the event list contain enough bytes for a possible
ClassesChangedEvent lateron.
The latter is used to increase the amount of allocated memory for the event
list. This will be needed for ClassesChangedEvents that can be of more or less
arbitrary size (larger than 32 anyway).
Rather than letting the DDX allocate the events, allocate them once in the DIX
and just pass it around when needed.
DDX should call GetEventList() to obtain this list and then pass it into
Get{Pointer|Keyboard}Events.
AllowAll is the last check before the parent window is checked. This allows
to override a DenyAll in the parent window in a simpler way than before (the
previous method required all devices to be in the permit list).
In the case that the device cursor was the first in the list of cursors
the window knew about, unsetting the cursor could lead to a segfault
due to pPrev being NULL. Instead catch the condition and correctly remove
the node from the list. Since there is no cursor now set on the device,
we simply return success as the parent windows cursor will propogate
down later.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
Relative events that generates both core and extention
events will have its axis cliped and screen changed by
miPointerSetPosition when the events are processed. For
absolute and non core-generating relative events the
axis must be clipped if we shouldn't end up completely
outside the defined ranges (if any).
Don't use a possitive value as a marker for if a max-value
is defined on the valuators. Use the existence of a valid
value range instead. This will also make it possible to
define arbitrary start and end-values for min and max as
long as min < max.
The correct thing would be to return the ClientPointer. However, if the client
for some reason has a core grab on another device (e.g. as result of a passive
grab), return the coordinates of the grabbed device instead.
This makes the use of nautilus a bit saner.
If the window being changed is set as the motion hint window for any device,
the device's motion hint window is set to NULL. Which is kinda what the old
code did, except that it did it with only the VCP.
Composite uses an unmap/map cycle to trigger backing pixmap allocation
and cliprect recomputation when a window is redirected or unredirected.
To avoid protocol visible side effects, map and unmap events are
disabled temporarily. However, when a window is unmapped it is also
removed from grabs and loses focus, but these state changes are not
disabled.
This change supresses the unmap side effects during the composite
unmap/map cycle and fixes this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=488264
where compiz would cause gnome-screensaver to lose its grab when
compiz unredirects the fullscreen lock window.
This is a significant shift in how input events are perceived. The common
approach was to treat a core event as a different entity than the XI event.
This could result in the XI event being delivered to a different client than
the core event. This doesn't work nicely if they come from the same device.
Instead, we treat an input event as a single event, that is delivered through
two separate APIs. So when delivering an event, we first try the XI event,
then the core event. If the window want's neither, we go to the parent and
repeat. Once either core or XI has been delivered, the processing stops.
Important: Different to the previous method, if a client registers for core
button events, the parent window will not get XI events. This should only
cause problems when you're mixing core and XI events, so don't do that!
Generic events don't fit into this yet, they cause me headaches.
This should restore the correct passive grab processing. When checking for
passive grabs, the core event is emulated and we check first for XI grabs on
the window, then for core grabs. Regardless of which event activates the grab,
the XI event is stored in the device's EQ.
When replaying the event, we take the XI event and replay it on the next
window, again including the emulation of the core event.
If two devices are attached to the same master device, pressing button 1 on
each of them leads to two button presses from the same device. Some apps
really don't like that.
So we just put a counter in place and only send the first press and the last
release.
(first_valuator + num_valuators) must never be larger than the number of axes,
otherwise DIX freaks out. And from looking at libXI, anything larger than 6 is
wrong too.
(cherry picked from commit 9f6ae61ad1)
General code cleanup, whitespace, dead code removal, added missing prototypes.
Made Xquartz come to foreground later in startup, so it doesn't appear for Xquartz -version
(cherry picked from commit 36922e8ff4316c93843aa3fe959cf8df3c7d5892)
From the X11 protocol spec:
"If background None is specified, the window has no defined background."
This means that toolkits and apps cannot rely on the "transparent" nature
of the current implementation! At some point before the next release,
XACE will switch back to a solid background as the default.
(first_valuator + num_valuators) must never be larger than the number of axes,
otherwise DIX freaks out. And from looking at libXI, anything larger than 6 is
wrong too.
Initialise num_events to 1, so we always send a proximity event, and then
optionally valuator events. Also make sure mieq can deal with valuator
events sent after proximity events.
If we have one global filter, one pointer may change the filter value and
affect another pointer.
Reproduceable effect:
blackbox and xterm, start dragging xterm then click anywhere with the other
pointer (attached to different masterd device!). The button release resets
the filter[Motion_Filter(button)] value, thus stopping dragging and no event
is sent to the client anymore.
Having the filters set per device gets around this.
In some cases (e.g. using x2x) the previous model broke, with a window ending
not counting down to 0 anymore. Special treatment for NotifyUngrab seems to
help here.
Current solution: If a NotifyGrab is to be sent ignore it. If a NotifyUngrab
enter is sent, only adjust the semaphore if it is on 0. Likewise, do the same
for a NotifyUngrab leave if the semaphore is on 1. This seems to work alright
so far.
We free the ValuatorClassRec quite regularly. If a SIGIO is handled while
we're swapping device classes, we can bring the server down when we try to
access lastx/lasty of the master device.
XkbInitKeyboardDefviceStruct may call FatalError if it fails. FatalError then
cleans up all the devices, resulting in a segfault if the pointer is
uninitialised.
Old code was fundamentally broken, fixes now are:
- free the MDs current device classes
- copy the device classes instead of flipping the pointers
- check for the old MD, not the new one.
Anything in dev->key, dev->valuator etc. of a MD must always be a copy of the
original class. The intial classes of an MD (the ones set up before an SD is
attached) as well, as we may have to restore them if no SD is attached
anymore.
Turns out it's really really hard synchronising device state across multiple
duplicated events if they all share the same struct. So instead of doing so,
when the SD changes deep-copy all it's classes into the MD. The MD then has
the same capabilities, but the state can be set separately. This should fix
xkb, key state, repeat etc. problems.
Updating the device state allows us to remove the SwitchCoreKeyboard from the
event gathering, it's all done during event processing now.
If a slave device is attached to a master device, then we need to send a
mapping notify to the client.
Mapping notify needs to be sent if
- different slave device but on same master
- different master
This gives you funny behaviour with the ClientPointer. When a
MappingNotify is sent to the client, the client usually responds with a
GetKeyboardMapping. This will retrieve the ClientPointer's keyboard mapping,
regardless of which keyboard sent the last mapping notify request. So
depending on the CP setting, your keyboard may change layout in each app...
This can happen if we check for a passive core grab and our device is a
floating slave device. Doesn't really change anything as SDs can't send core
events but it stops the server from segfaulting.
Each time a different slave device sends through a master, an
DeviceClassesChangedEvent is enqueued. When this event is processed, all
classes of the matching master device are changed, and the event is sent to
the clients.
Next time the master is queried, it thus shows the evclasses of the last slave
device. The original classes are stored in the devPrivates.
TODO: if all slave devices are removed, the master's original classes need to
be restored.
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.
Sascha Hlusiak
Eamon Walsh
Peter Hutterer
Adam Jackson
Chris Wilson
Benjamin Close
Daniel Stone
Magnus Vigerlöf
Matthieu Herrb
Kristian Høgsberg
Alan Coopersmith
Jeremy Huddleston
Bartosz Fabianowski
Jeremy Huddleston
Ben Byer
Aaron Plattner
Naoki Hamada
Dodji Seketeli
Dodji Seketeli