xf86-input-libinput: Changes to 'master'
Peter Hutterer
whot at kemper.freedesktop.org
Thu Nov 19 14:46:12 PST 2015
src/xf86libinput.c | 480 ++++++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 400 insertions(+), 80 deletions(-)
New commits:
commit c943739a2bfd4c380db0b21bc35b73deb7496c8a
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date: Wed Nov 11 10:10:58 2015 +1000
Split mixed pointer/keyboard devices into two separate X devices
The server struggles with devices that are both, the protocol (especially XI2)
requires a fairly strict separation of pointer vs keyboard devices. Though the
server has a couple of hacks to route events correctly, mixed
devices still experience bugs like [1].
Instead of advertising the device as a single mixed device, split the device
into two X devices, one with only a pointer/touch component, one with only a
keyboard component. This ensures that the device is effectively attached to
both the VCP and the VCK, something the XI2 protocol doesn't really allow.
This patch drops the keyboard capability on a mixed device, duplicates the
input options and attributes and queues a NewInputDeviceRequest call. The new
device only has the keyboard capability but is otherwise unchanged. The
wacom driver has used this approach for years.
The WorkProc is necessary to avoid inconsistent state, the server doesn't
handle a NewInputDeviceRequest during PreInit well.
The approach:
During pre-init we create a struct xf86libinput_device with the
libinput_device and a unique ID. The child device has that ID added to the
options and will look for the other device during its pre-init. The two
devices then share the xf86libinput_device struct.
We only have a single epollfd for all devices and the server calls read_input
on the first device in the list with the epollfd as pInfo->fd. That shared
struct is used as the userdata on the libinput_device we get back from the
event, and each device is in the xorg_list device_list of that shared struct.
We loop through those to find the ones with the right capabilities and
post the event through that device.
Since devices can be enabled and disabled independently, the rest of the code
makes sure that we only ever add the device to libinput when the first shared
device is enabled, and remove it accordingly.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=49950
https://bugs.freedesktop.org/show_bug.cgi?id=92896
Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
Reviewed-by: Hans de Goede <hdegoede at redhat.com>
commit a72e96538af2c4a94ead48f96e8e59a2a4980a64
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date: Fri Nov 13 09:39:29 2015 +1000
Add a helper function for the driver context initialization
Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
Reviewed-by: Hans de Goede <hdegoede at redhat.com>
commit b1a9bea6079550fa8be4fa0b2e18ea810b0ea68c
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date: Wed Nov 11 09:12:33 2015 +1000
Copy the device capabilities to the X driver struct
And use those copied caps instead of the direct device capability calls.
No functional changes at this point, this is preparation work for selectively
disabling capabilities on a device.
Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
Reviewed-by: Hans de Goede <hdegoede at redhat.com>
commit a6aad69a97c68fa96e0a836e735b1a7f319b92df
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date: Wed Nov 11 09:02:22 2015 +1000
Split type_name detection out into a helper function
No functional changes
Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
Reviewed-by: Hans de Goede <hdegoede at redhat.com>
More information about the xorg-commit
mailing list