xf86-input-libinput: Changes to 'master'
Peter Hutterer
whot at kemper.freedesktop.org
Sun Dec 7 14:42:37 PST 2014
src/libinput.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 121 insertions(+), 5 deletions(-)
New commits:
commit 0c4eaf5480168b468547cdb3bd8ce5247b5a5378
Author: Peter Hutterer <peter.hutterer at who-t.net>
Date: Tue Dec 2 12:29:07 2014 +1000
Support server-side fds
libinput's device handling and server-side fd handling are a bit of a
mismatch, so this is hackier than one would hope for.
The server sets pInfo->fd and the options "fd" and "device".
The server requires pInfo->fd to be the one triggering select(2) to call the
correct pInfo->read_input. We can't pass an fd to use into libinput, all we
have is the open_restricted callback. That callback gives us the context, but
not the pInfo with the fd we want.
The solution:
1) In PreInit, store the patch + fd combination in a driver-wide list. Search
that list for an fd in open_restricted, return the pre-openend fd.
2) Overwrite all devices' pInfo->fd with the libinput epollfd. In this driver
we don't care about which device read_input is called on, we get the correct
pInfo to post events from through the struct libinput_device of the libinput
events.
3) When a device is closed, swap the real fd back in so systemd-logind closes the
right fd.
This saves us worrying about keeping the right refcount on who currently has
the fd set to the libinput fd. We just set it for all devices, let the server
figure out which device to call (the first in inputInfo.devices) and we only
need to remember to swap it back during DEVICE_OFF.
If the server calls close on a pInfo->fd without telling the driver, that's a
bug anyway.
This patch also drops the pInfo->fd = -1 calls, they've been unnecessary since
at least 1.11, possibly earlier.
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