Note: ABI break, but ABI_XINPUT_VERSION has NOT been bumped. Recompile input
drivers.
Revert "Xi: return BadImplementation for deviceids 256 and above"
This reverts commit 2b459f44f3.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous code would always skip the last valuator due to a wrong
upper boundary in the loop. last_valuator is the index of the last set
valuator - which also means it must be initialized to -1, not 0.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some files (notably those merged with MPX before XI2 came along) didn't use
a 'xi' prefix. This patch changes all of them to meaningful names.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If SetClientPointer fails, the only reason may be that the device is not a
pointer or that the device is an SD. Return BadDevice instead of BadAccess.
(BadAccess is a leftover from the early times of the ClientPointer
implementation when only one client was allowed to set it).
If the window parameter doesn't name a valid window or client, return
BadWindow.
Finally, allow both master keyboards and master pointers as deviceid.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was quite old code and can be streamlined a bit. The new code is
essentially the same as in ProcXISetClientPointer.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Swapping the mask_len and then advancing the pointer by the swapped length
is just a bad idea.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The maximum number of bytes is calculated by the mask len, and the mask len
is always in 4-byte units. XI2MASKSIZE however is in bytes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
zero-length masks are supposed to clear the device's mask.
ProcXISelectEvents passes these masks through directly, so we need to clear
the bits here if such a mask is supplied.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The data is already swapped before, so we just post it to the client as-is,
without attempting to swap it again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
inputstr includes XI2proto.h for the sole purpose of XI_LASTEVENT.
However, using XI_LASTEVENT in the server is prone to errors, if the server
is recompiled against a newer version of the protocol it would bump this
variable and associates bits, including potential ABI.
This patch defines an XI2LASTEVENT for use in the server and removes the
XI2proto.h require. XI2LASTEVENT is the current value of XI_LASTEVENT.
This patch is required by components that require access to inputInfo
(currently xf86-video-geode and xf86-video-cirrus) but should not have a
require for the XI2 protocol.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two issues that combined to false positives and false negatives.
- The checking for invalid bits must be performed when there are enough bits
that an event outside of LASTEVENT may be selected.
- The first invalid bit is LASTEVENT + 1, not LASTEVENT.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The protocol allows for 16 bit device ids, but the implementation doesn't
yet. We need to break the input ABI once more to shift the DeviceIntRec's
CARD8 to a CARD16, along with some changes in the privates.
Once that is done, revert this patch.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The server returned the minimum of major/minor each instead of the lower of
the combined major.minor version. As a result, a client reporting
3.0 and a server supporting 2.7, the return value would be 2.0 (the minimum
of both).
Reported-by: Rémi Cardona
Reported-by: Simon Thum
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
XIQueryVersion must return the client's version if the client's version is
lower than or equal to the server's version, or the server's version
otherwise.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
86077f0058ce88ee9b3df5d1ab854eeca43 switched from a boolean to a grabtype
enum. ProcXGrabDevice didn't switch with it. PickPointer during an XI grab
on a slave device would thus return a wrong (or NULL) device and crash the
server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
These grabs are suported through two fake devices inputInfo.all_devices and
inputInfo.all_master_devices. These devices are not part of the device list
and are only initialised for their device id, nothing else.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's use-cases where this is useful, so take the check out preventing
that.
Reported-by: Thomas Jaeger
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a passive enter or focus in grab activates, send additional enter or
focus events with mode XIPassiveGrabNotify to the grabbing client.
Likewise, if the grab deactivates, send additional leave or focus out
events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Enter grabs are checked for in CheckMotion(), each time the sprite window
changes the current grab is deactivated (if applicable) and the new grab is
activated (if applicable). Exception - if the grab is on a parent window of
the current window since we keep the grab across descendants.
Since CheckMotion() may change the grab status of a device, we mustn't get
"dev->deviceGrab.grab" in ProcessOtherEvents until after CheckMotion().
FocusIn grabs are checked in much the same manner.
The event delivery for grabs replaces the NotifyNormal on window change with
a NotifyGrab on window change. Note that this happens before the grab
activates, so the EnterNotify(NotifyGrab) is still delivered to the window,
not to the grabbing client. This is in line with the core protocol semantics
for NotifyGrab events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not having the resource mask set means we never match an existing grab,
hence we never actually ungrab.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer