This variable was used originally to determine which client is allowed to
change the pointer-keyboard pairing. For now, we just let anyone change it and
see how that works out.
(cherry picked from commit 4e2c6dbabdbbaaca213fd08edd422de15d0900cc)
required because of commit 7c0709a736,
which made requestingClient in dix specific to Xprint only.
Add to XPRINT_LIBS in hw/xprint/Makefile.am in front of
$(XSERVER_LIBS) to override definitions in libdix.la for standard xservers.
Follows 571206832d (providing -DXPRINT
to xprint subdirs).
Note it may be possible to restructure the code so that
requestingClient is stored elsewhere than in dix. See discussions
following http://lists.freedesktop.org/archives/xorg/2008-March/033844.html
If this is done it may be possible to revert this commit (if not 571206...).
Rather than freeing/allocing classes each time the device capabilities need to
swap, store them in the devPrivates system.
When a class is unused, it is pushed into the devPrivates, and later recovered
when needed again. This saves us a lot of memory allocations/frees, admittedly
on the cost of some memory.
The DDX (xfree86 anyway) maintains its own device list in addition to the one
in the DIX. CloseDevice will only remove it from the DIX, not the DDX. If the
server then restarts (last client disconnects), the DDX devices are still
there, will be re-initialised, then the hal devices come in and are added too.
This repeats until we run out of device ids.
This also requires us to strdup() the default pointer/keyboard in
checkCoreInputDevices.
X.Org Bug 14418 <http://bugs.freedesktop.org/show_bug.cgi?id=14418>
The device classes aren't deleted anymore on a class change, so there's no
need to store the MD's original classes. We should however restore the MD to
sane defaults when disconnecting the last device, consider this as TODO item.
Instead of a simple counter, use bits to keep track of which device is where
etc. When device enters a window (or sets focus), the bit matching the device
is set, when it leaves again, it is unset. If there are 0 bits set, then
Leave/Enter/Focus events may be sent to the client.
Same theory as before, but this should get around the insanity with
Grab/Ungrab special cases. Those cases are basically untested though.
If an pointer event is being processed during a device grab, don't deliver it
to the focus window, even if the device has a focus class. Reason being that
some pointers may have a focus class, thus killing drag-and-drop.
InitializeSprite won't create a new one if it already exists, with the result
of overwriting the master's sprite. This master sprite is then assigned to the
floating slave, and freed when the slave is reattached later.
Setting the sprite to NULL forces InitializeSprite to alloc a new one, and
this one can be freed without further repercussions.
Add Prox events to the if-clauses with the other events
that are usually sent from the input devices.
Ensure that the event deliverers won't try to deliver
events of type '0' (some extended events doesn't have
an equivalent core-type)
Small modification by Peter Hutterer.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
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)
