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@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Detecting them is a bit of guesswork: if a device is a pointer device and has
a calibration matrix option, then the device must be an abs device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Clients need to know which methods are available, not just which one
is currently set. Export bitmask config options as two properties,
one read-only named "... Available" and one set-able one named "... Enabled"
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Clients need to know which methods are available, not just which one is
currently set. Export bitmask config options as two properties, one read-only
named "... Available" and one set-able one named "... Enabled"
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the driver doesn't have a pInfo reference anymore for a libinput device,
don't bother processing events, the device was already removed. This was
triggered by the libevdev test suite which adds/removes devices very quickly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This currently exposes the libinput button name, which isn't ideal. Needs to
be switched to X button numbers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Let the server filter based on the verbosity levels in the server, so map
ERROR to -1 (always), INFO to 3 (default verbosity) and DEBUG to 10.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This only makes room for the highest button number present on the device, it
doesn't cater for devices with 'holes'. i.e. if a device has only BTN_BACK, it
will initialize buttons for all below too.
Which is also evdev's current behavior.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Less code this way, though if we somehow sneak in a bad option we get the
error for it every time we update any property.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The property support isn't ideal, the server relies on the driver to check
first if a setting is possible, applying the setting itself cannot fail.
Thus we can't just check the libinput config status code, which matters mostly
in the sendevents property where we simply check that only a single bit is set
and that the supported modes are equal or more to the requested mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Once we turn the device off, we may still get events from it but the pInfo
struct may not be valid anymore to process those events.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allows us to use subpixel data, not that the server does a good job with it.
But at least for scrolling we should now be able to scroll by small amounts
too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
the kernel does not send any ABS_MT_POSITION_X|Y data while releasing
the touch, so use the previous values to set the position of the release.
If it's not done, the touch up occurs at (0,0) and moves dragged elements
to the upper right corner.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We open and remove the device immediately, but the fd was left on the old
value. This makes debugging harder, since the fd looks correct when it isn't.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
libinput currently scales wheel events by DEFAULT_AXIS_STEP_DISTANCE,
which is currently 10.
We may be able to find the value automatically, but it would require
some dark codings that may not be robust.
For the time being, just duplicate the define in libinput.c and remember
to update it if it is changed in the future.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
All libinput devices share the same file descriptor so make sure we don't
remove from the server's select loop until the last device is disabled.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Whatever xf86AddEnabledDevice does to the fd, it doesn't work with an
epollfd. Should probably investigate that further.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
