When we send BadValue back to the client for having invalid mask bits,
at least tell them what the (first) invalid bit was.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
If any part of the stack calls XIGetKnownProperty during device shutdown
the property is re-initialized before the server generation resets, leaving
the value invalid again.
Move the reset to the extension init which happens before input devices are
initialized before the first property is requested.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
When getting close to the MAXDEVICES limit, the creation of XTEST devices
may fail due to device id exhaustion. In that case, fail the creation of
master devices too and return an error to the client.
Theoretically, we could alloc the MDs without the XTEST devices but that
will get interesting when a client starts sending XTEST events through those
devices.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
They were named ptr when everything was in one function to save one more
variable. Now that the stuff is split out, "dev" makes more sense.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
No functional changes, just code cleanup to improve readability.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
From the original bug reporter Ezra Reeves:
"I did some more digging on this today, and I found that an HP branded
wireless USB mouse has the same issue. With this mouse (as well as the
logitech wireless mouse), the return from:
xdev = XListInputDevices(GDK_WINDOW_XDISPLAY(rootwin), &ndevices_return);
lists the USB device twice, but both have xdev[num].use == 3
(IsXExtensionKeyboard as defined in X11/XI.h).
[...]
Swapping the order of the test in Xi/listdev.c that determines whether a
device is a pointer or a keyboard properly detects my devices (OEM USB
wireless mouse/kb combo) -- one as a keyboard and one as a pointer."
X.Org Bug 29046 <http://bugs.freedesktop.org/show_bug.cgi?id=29046>
Reported-by: Erik Kilfoil <ekilfoil@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
This hook wasn't used by any DDX. Device addition and removal is handled by
the config backend, so we don't need to do anything special that during the
ListInputDevices request processing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
In theory, these hooks were to be used for DDX-specific device enablement.
None of the DDXs however did anything here. Now we call DEVICE_INIT on all
devices when they are added, so the xfree86 DDX as the only one with real
code didn't do anything here.
kdrive checked for device validity but that's already handled in
ProcXOpenDevice.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
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>
This patch has been generated by the following Coccinelle semantic patch:
@@
expression E;
@@
-if(E) { free(E); }
+free(E);
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Reviewed-by: Fernando Carrijo <fcarrijo@yahoo.com.br>
Reviewed-by: Matt Turner <mattst88@gmail.com>
This patch only changes the API, not the implementation of the
devPrivates infrastructure. This will permit a new devPrivates
implementation to be layed into the server without requiring
simultaneous changes in every devPrivates user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Many references to the dixScreenOrigins array already had the
corresponding screen pointer handy, which meant they usually looked like
"dixScreenOrigins[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 declared the dixScreenOrigins array, I figure allocating a
screen private for these values is overkill.
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)
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)
For absolute input devices (E.G. touchscreens) in multi-head setups,
we need a way to bind the device to an randr output. This adds the
infrastructure to the server to allow us to do so.
positionSprite() scales input coordinates to the dimensions of the shared
(total) screen frame buffer, so to restrict motion to an output we need to
scale/rotate/translate device coordinates to a subset of the frame buffer
before passing them on to positionSprite.
This is done here using a 3x3 transformation matrix, which is applied to
the device coordinates using homogeneous coordinates, E.G.:
[ c0 c1 c2 ] [ x ]
[ c3 c4 c5 ] * [ y ]
[ c6 c7 c8 ] [ 1 ]
Notice: As input devices have varying input ranges, the coordinates are
first scaled to the [0..1] range for generality, and afterwards scaled
back up.
E.G. for a dual head setup (using same resolution) next to each other, you
would want to scale the X coordinates of the touchscreen connected to the
both heads by 50%, and translate (offset) the coordinates of the rightmost
head by 50%, or in matrix form:
left: right:
[ 0.5 0 0 ] [ 0.5 0 0.5 ]
[ 0 1 0 ] [ 0 1 0 ]
[ 0 0 1 ] [ 0 0 0 ]
Which can be done using xinput:
xinput set-prop <left> --type=float "Coordinate Transformation Matrix" \
0.5 0 0 0 1 0 0 0 1
xinput set-prop <right> --type=float "Coordinate Transformation Matrix" \
0.5 0 0.5 0 1 0 0 0 1
Likewise more complication setups involving more heads, rotation or
different resolution can be handled.
Signed-off-by: Peter Korsgaard <peter.korsgaard@barco.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter wants to get a larger patch sequence put together and I didn't
read past the commit message to see the 'don't take this patch
please'.
This reverts commit 531ff40301.
Some input drivers need to implement an internal hotplugging scheme for
dependent devices to provide multiple X devices off one kernel device file.
Such dependent devices can be added with NewInputDeviceRequest() but they are
not removed when the config backend calls DeleteInputDeviceRequest(),
leaving the original device to clean up.
Example of the wacom driver:
config/udev calls NewInputDeviceRequest("stylus")
wacom PreInit calls
NewInputDeviceRequest("eraser")
NewInputDeviceRequest("pad")
NewInputDeviceRequest("cursor")
PreInit finishes.
When the device is removed, the config backend only calls
DeleteInputDeviceRequest for "stylus". The driver needs to call
DeleteInputDeviceRequest for the dependent devices eraser, pad and cursor to
clean up properly.
However, when the server terminates, DeleteInputDeviceRequest is called for
all devices - the driver must not remove the dependent devices to avoid
double-frees. There is no method for the driver to detect why a device is
being removed, leading to elaborate guesswork and some amount of wishful
thinking.
Though the input driver's UnInit already supports flags, they are unused.
This patch uses the flags to supply information where the
DeleteInputDeviceRequest request originates from, allowing a driver to
selectively call DeleteInputDeviceRequest when necessary.
Also bumps XINPUT ABI.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
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>
Properties allocated through XIGetKnownProperty() aren't reset on the second
server generation but keep the old value. As a result, wrong Atoms are
supplied to the driver, resulting in potential data corruption or weird
error message.
Reproducible by running "xlsatom | grep FLOAT" twice on a plain X server.
The second X server generation won't have the FLOAT atom defined anymore,
despite the users of this atom not noticing any errors.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
In the process, fixes a memory leak in CloseDevice, and an unchecked
memory allocation in InitializePredictableAccelerationProperties.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Both dev and dev->button are already used before their checking were being
performed. So check on the beginning.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Error was introduced in 31a7994a. I.e., broken since 2007. I guess nobody uses
XSendExtensionEvent.
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reintroduce a check which used to be there in the old
ProcessKeyboardEvent/ProcessPointerEvent codepath, which avoids us
recording events subject to a grab twice: once when it's first processed
in EnqueueEvent, and then again when it's thawed and being replayed.
This required a tiny amount of code motion to expose syncEvents.
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>
The XI protocol spec only allows for two errors on the SetDeviceMode
requests: BadMatch or BadMode. BadMode however is a dynamically assigned
extension error and the driver doesn't have access to the actual error
number. Hence, if a SetDeviceMode driver returns an error other than
BadMatch, assume BadMode.
The two exceptions are BadAlloc and BadImplementations, pass these on to the
client (any request is allowed to return either of those).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
RECORD was disabled during the switch to internal events. This patch
modifies the record callback to work with internal events instead of
xEvents. The InternalEvents are converted to core/Xi events as needed.
Since record is a loadable extension, the EventTo* calls must be externed.
Signed-off-by: Chris Dekter <cdekter@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the indicator flags have the XkbSLI_IsDefault bit set, the indicator map
and names aren't their own bit of memory but rather point into the
device->key->xkbInfo->desc structure. XkbCopySrvLedInfo knows about this and
leaves the pointers alone.
When copying the classes from the slave to the master, these pointers are
copied and still point to the dev->key class of the slave device. If the
slave device is removed, the memory becomes invalid and a call to modify
this data (e.g. XkbSetIndicators) may cause a deadlock.
The copying of dev->key relies on dev->kbdfeed to be already set up. Hence
the pointers need to be reset once _both_ kbdfeed and key have been copied
into the master device.
X.Org Bug 25640 <http://bugs.freedesktop.org/show_bug.cgi?id=25640>
Fedora Bug 540584 <https://bugzilla.redhat.com/show_bug.cgi?id=540584>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Thoses definitions have been included in the kernel but the X server is not updated accordingly.
Without these definitions, the multitouch axes are not correctly labelled.
Signed-off-by: Benjamin Tissoires <tissoire@cena.fr>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In order to give NewInputDeviceRequest more information, a new
InputAttributes type is introduced. Currently, this collects the product
and vendor name, device path, and sets booleans for attributes such as
having keys and/or a pointer. Only the HAL backend fills in the
attributes, though.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
Convert all calls of CreateNewResourceType to pass name argument
Breaks DIX ABI.
ABI versions bumped:
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Make sure to check return value before setting bitmask flags.
For most calls, just fails to init the extension. Since Xinput
already calls FatalError() on initialization failure, so does
failure to allocate Xinput's resource type.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Commit 0e6cee853d introduced cleanup code to
remove the accel properties when switching schemes. The same code is
triggered by the default closedown code but only after unconditionally
removing all device properties (as part of the cleanup). The properties,
although deleted never got reset to NULL.
X.Org Bug 25374 <http://bugs.freedesktop.org/show_bug.cgi?id=25374>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Andy Furniss <lists@andyfurniss.entadsl.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Trying to unregister property handlers during the device closure process
leads to invalid memory accesses.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Deleting a property that was not set on a device leads to a null-pointer
reference. The protocol allows deleting those properties - it has to be a
noop.
Reproducible:
xinput --set-prop "My device" --type=int --format=8 "my property" 1
xinput --delete-prop "My other device" "my property"
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Instead of returning BadAccess when "read" permission is denied
on a device, falsify the device state (buttons down, keys pressed).
This is nicer to applications, but may still have undesired side
effects. The long-term solution is not to use these requests in
event-driven code!
Requests affected: QueryPointer, QueryKeymap, XiQueryDevice.
Signed-off-by: Eamon Walsh <ewalsh@tycho.nsa.gov>
