Functional change: for a button mapped to 0, the motionHintWindow is not
updated to the NullWindow anymore. Before it got updated unconditionally to
the button mapping. I have no idea what the practical effect of this is, but
I guess it's closer to the correct behaviour: pressing a button that's
logically disabled now does not disrupt the motion hint delivery.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
'state' is shadowed by the XKB 'state' as well (which feeds into the event
too), so rename this one to clarify that this is the core event state only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Once grabs start having nested memory locations, we can't just use the
GrabRec on the stack anymore, we need to alloc/copy/free the grabs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Does what it says on the box, complements MakeInputMask.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Currently not needed since the InputClientRec is a self-contained struct. As
part of the touch rework that won't be the case in the future and a function
to allocate/free memory appropriately is required.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Wherever it's obvious which device we need (keyboard or pointer), use
GetMaster() instead of GetPairedDevice(). It is more reliable in actually
getting the device type we want.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
They don't have a KeyClassRec, but we must still allow passive grabs on
them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Bastien Nocera <hadess@hadess.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
If we're sending the event for a given device, make sure the deviceid is
that of the device.
This allows callers to use the same DCE for slave and master without having
to fiddle the DCE's internal fields.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Instead of device and master (and just using master), drop the master
argument and let the callers pass in the device the event is to be sent for.
No effective functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
For scroll wheel support, we used to send buttons 4/5 and 6/7 for
horizontal/vertical positive/negative scroll events. For touchpads, we
really want more fine-grained scroll values. GetPointerEvents now
accepts both old-school scroll button presses, and new-style scroll axis
events, while emitting both types of events to support both old and new
clients.
This works with the new XIScrollClass to mark axes as scrolling axes.
Drivers mark any valuators that send scroll events with SetScrollValuator.
(Currently missing: the XIDeviceChangeEvent being sent when a driver changes
a scroll axis at run-time. This can be added later.)
Note: the SCROLL_TYPE enums are intentionally different values to the XI2
proto values to avoid copy/overlapping range bugs.
Co-authored-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Relative axes are initialized with 0, -1 but so far this never had any
effect as all users of this function (for relative axes) just set it to the
defaults anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Return errors instead of silently ignoring them.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Change the DeviceEvent InternalEvent to use doubles for its valuators,
instead of data and data_frac.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
exevents.c: In function 'UpdateDeviceState':
exevents.c:719:9: warning: variable 'bit' set but not used
[-Wunused-but-set-variable]
exevents.c: In function 'ProcessOtherEvent':
exevents.c:889:22: warning: variable 'v' set but not used
[-Wunused-but-set-variable]
exevents.c:888:17: warning: variable 'k' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
No functional changes, prep work for future changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Cyril Brulebois <kibi@debian.org>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The macro is sufficient if called during a development cycle, but not
sufficient information when triggered by a user (e.g.
https://bugzilla.redhat.com/show_bug.cgi?id=688693).
Expand what this does to print the event content and a backtrace, so at
least we know where we're coming from. Only the first 32 bytes are printed
since if something goes wrong, the event we have is almost certainly an
xEvent or xError, both restricted to 32 bytes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
commit 678f5396c9 only fixed the
initialization, not the copy. After a slave device change, the valuator
were out of alignment again.
X.Org Bug 36119 <http://bugs.freedesktop.org/show_bug.cgi?id=36119>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This removes the struct, but keeps InitAbsoluteClassDeviceStruct as
a no-op and preserves related struct layout.
Signed-off-by: Simon Thum <simon.thum@gmx.de>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is not a straightforward search/replacement due to a long-standing
issue.
dev->u.master is the same field as dev->u.lastSlave. Thus, if dev is a master
device, a check for dev->u.master may give us false positives and false
negatives.
The switch to IsFloating() spells out these cases and modifies the
conditions accordingly to cover both cases.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
These two were sideeffects of lastSlave being in the same field as the
master. For devices generated by the master device directly, lastSlave was 0
and the device would (with the old checks) be interpreted as floating.
Add the required checks to safeguard against master devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Benjamin Tissoires <tissoire@cena.fr>
When a client has selected for Xi 1.x DeviceStateNotify events, they
should receive them when a DeviceFocusIn event is generated. The code
to do this was there, but an incorrect test meant they were never being
sent.
The "type" passed in is the XI2 type, the XI1 type is in event.type.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
CheckDeviceGrabs will activate a passive grab for KeyPress and
ButtonPress events. GrabInfoRec::activatingKey contains the keycode
which activated the passive grab, so we can deactivate it later in
ProcessOtherEvents.
Previously, CheckDeviceGrabs relied on its callers to set
activatingKey, which not all callers were doing (I'm looking at you,
ComputeFreezes). Just set it in CheckDeviceGrabs instead.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since FixUpEventFromWindow only uses the sprite trace to determine the
window stack, pass in a sprite instead of hardcoding the device sprite,
so we can deliver to windows other than the one currently containing the
sprite.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
It is currently assumed that an event button delieved to a master device
corresponds to the slave button states. However, the event button is a
logical (mapped) slave button and slave button states correspond to
physical (unmapped) slave buttons. This leads to incorrect update of the
master button state and incorrect events devlivered to clients. Fix the
situation by taking the slave button map into account when querying a
slave button state.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=24887
Signed-off-by: Eoghan Sherry <ejsherry@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have per-axis mode now. For those bits that still need it (XI 1.x),
assume that the first axis holds the device's mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Previously the OutOfProximity bit in the valuator mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The XI2 protocol supports per-axis modes, but the server so far does
not. This change adds support in the server.
A complication is the fact that XI1 does not support per-axis modes.
The solution provided here is to set a per-device mode that defines the
mode of at least the first two valuators (X and Y). Note that initializing
the first two axes to a different mode than the device mode will fail.
For XI1 events, any axes following the first two that have the same mode
will be sent to clients, up to the first axis that has a different mode.
Thus, if a device has relative, then absolute, then relative mode axes,
only the first block of relative axes will be sent over XI1.
Since the XI2 protocol supports per-axis modes, all axes are sent to the
client.
Signed-off-by: Chase Douglas <chase.douglas@canonical.com>
RegisterPointerDevice() and RegisterKeyboardDevice() were already mapped to
RegisterOtherDevice() and obsolete.
RegisterOtherDevice() was called for all devices and the two assignments can
simply be moved into AddInputDevice(). Purge RegisterOtherDevice() and
pretend it never happened.
*lalalalala*
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
After copying the unused_classes into the device, reset the original
pointer. Otherwise we have two pointers pointing to the same field and both
get freed on device removal.
Some classes already have this behaviour since 51c8fd69.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Same as the matching key functions. Buttons, like keys, can have two states
for down/up - one posted, one processed. Posted is set during event
generation (usually in the signal handler). Processed is set during event
processing when the event queue is emptied and events are being delivered to
the client.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The modifier key count is maintained by the XKB layer and
increased/decreased for all modifiers that set state.
Test case, MD/SD modifier key count in comment:
1. keyboard 1: press and hold Shift_L # SD:1 MD:1
2. keyboard 2: press and release Shift_L # SD:1,0 MD:1,0
<class copy happens> # SD:1 MD:1
3. keyboard 1: release Shift_L # SD:0 MD:1
4. keyboard 1: press and release Shift_L # SD:1,0 MD:2,1
The modifier is now logically down on the MD but not on keyboard 1 or
keyboard 2.
XKB is layered in before the DIX, it increases/decreases the modifier key
count accordingly. In the above example, during (2), the MD gets the key
release and thus clears the modifier bit. (3) doesn't forward the release to
the MD because it is already cleared. The copy of modifierKeysDown when the
lastSlave changes however increases the counter for the held key. On (4),
the press and release are both forwarded to the MD, causing a offset by 1
and thus do not clear the logical modifier state.
X.Org Bug 25480 <http://bugs.freedesktop.org/show_bug.cgi?id=25480>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Daniel Stone <daniel@fooishbar.org>
This patch was generated by the following Perl code:
perl -i -pe 's/([^_])return\s*\(\s*([^(]+?)\s*\)s*;(\s+(\n))?/$1return $2;$4/g;'
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Many references to the WindowTable array already had the corresponding
screen pointer handy, which meant they usually looked like
"WindowTable[pScreen->myNum]". Adding a field to ScreenRec instead of
keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
xf86-video-dummy currently uses WindowTable, so it needs to be updated
to reflect this change.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
Rather than always returning BadValue, associate an error status like
BadWindow with a resource type like RT_WINDOW, and return the
appropriate one for the requested type.
This patch only touches the core protocol resource types. Others still
return BadValue and need to be mapped appropriately.
dixLookupResourceByType can now return BadImplementation, if the caller
asked for a resource type that has not been allocated in the server.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Just let Dispatch() check for a noClientException, rather than making
every single dispatch procedure take care of it.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>