| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This lets the xfree86 layer change to the NotifyFd interface without
affecting the driver.
v2: Check for new API in configure.ac and use only if present
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
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.
The server uses pInfo->major/minor to detect if another device is using the
same path for a logind-controlled fd. If so, it reuses that device's
pInfo->fd and sets the "fd" option to that value. That pInfo->fd is the
libinput epollfd though, not the actual device fd.
This doesn't matter for us, since we manage the fds largely ourselves and the
pInfo->fd we use is the epollfd anyway. On unplug however, the udev code
triggers a device removal for all devices, including the duplicated ones. When
we disable device, we restore the pInfo->fd from the "fd" option so that the
server can request logind to close the fd.
That only works if the "fd" option is correct, otherwise the server asks
logind to close the epollfd and everyone is unhappy.
[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@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
When using logind, this causes the server to hang when a split device is
unplugged. The reason is mostly in the server, when open the device by
requesting the logind fd, the server loops through the device list to check if
any other device has the same major/minor (see systemd_logind_take_fd()) and
returns the pInfo->fd for that device instead of requesting the fd again from
logind.
For libinput devices, the pInfo->fd is the epollfd, not the actual device, so
our second device gets the epollfd assigned. When the devices are removed, we
keep the device fd open and release the epollfd through logind.
This reverts commit c943739a2bfd4c380db0b21bc35b73deb7496c8a.
|
|
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@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
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@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
No functional changes
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
A device that fails pre_init has a ref to the libinput context but may not
have a pInfo->private. For those devices we never call libinput_unref() and
the libinput struct never gets freed.
Thus if at least one device didn't pass pre_init, we never cleaned up after
ourselves.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
We're not doing anything here, so no reason to fail.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Obsolete as of 353c52f2bec03
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
No real effect in the current code, but it adds a bit of safety.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
If we install the config file by default, we shouldn't use libinput for
devices we know we can't handle.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
This way it still sorts after the usual subjects, but it's easier to stack
extra config in afterwards.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Takes a void*, not a void**
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Correct typo. Draging to dragging.
|
|
This will transparently handle server-side fds for us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Martin Pieuchot <mpi@openbsd.org>
|
|
The server already stores the server-fd in the options, so we only need to run
through the list of current devices, find a match and extract that fd from the
options. Less magic in our driver and it gives us a pInfo handle in
open_restricted which we'll can use for xf86OpenSerial().
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Martin Pieuchot <mpi@openbsd.org>
|
|
libinput always has horizontal scrolling enabled and punts the decision when
to scroll horizontally to the toolkit/widget. This is the better approach, but
while we have a stack that's not ready for that, and in the X case likely
never will be fully ready provide an option to disable horizontal scrolling.
This option doesn't really disable horizontal scrolling, it merely discards
any horizontal scroll delta. libinput will still think it's scrolling.
https://bugs.freedesktop.org/show_bug.cgi?id=91589
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
First, why is this here and not in libinput: drag lock should be implemented
in the compositor (not in libinput) so it can provide feedback when it
activates and grouped in with other accessibility features. That will work for
Wayland but in X the compositor cannot filter button events - only the server
and the drivers can.
This patch adds mostly the same functionality that evdev provides with two
options on how it works:
* a single button number configures the given button to lock the next button
pressed in a logically down state until a press+ release of that same button
again
* a set of button number pairs configures each button with the to-be-locked
logical button, i.e. a pair of "1 3" will hold 3 logically down after a
button 1 press
The property and the xorg.conf options take the same configuration as the
evdev driver (though the property has a different prefix, libinput instead of
Evdev).
The behavior difference to evdev is in how releases are handled, evdev sends
the release on the second button press event, this implementation sends the
release on the second release event.
https://bugs.freedesktop.org/show_bug.cgi?id=85577
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Martin Pieuchot <mpi@openbsd.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Martin Pieuchot <mpi@openbsd.org>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
To avoid conflict and confusion with libinput's sources. This was originally
triggered by needing a header file for the driver which cannot be named
libinput.h. That need went away after other refacturing, but we might as well
rename it now, sooner or later we'll need a xf86libinput.h file.
Can't do much about the libinput-properties header though, not worth breaking
other projects and it's namespaced into /usr/include/xorg anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
We don't do anything with them though.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1230945
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Even if no scroll method is enabled by default, we still want those
properties.
Introduced in 8d4e03570c.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
SDL Games like openarena rely on relative input that's handled by the DGA code
in the server. That code casts the driver's input data to int and sends it to
the client. libinput does pointer acceleration for us, so sending any deltas
of less than 1 (likely for slow movements) ends up being 0.
Use the new ValuatorMask accelerated/unaccelerated values to pass the
unaccelerated values along, the server can then decide what to do with it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
A lot of devices (mainly MS input devices) have abs axes on top of the
relative axes. Those axes are usually mute but with the current code we set up
absolute axes for those devices. Relative events are then scaled by the server
which makes the device appear slow.
As an immediate fix always prefer relative axes and only set up absolute axes
if the device has a calibration matrix but no pointer acceleration.
This may mess up other devices where the relative axes are dead, we'll deal
with this when it comes.
https://bugs.freedesktop.org/show_bug.cgi?id=90322
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
With a long entry in the man page to detail what this option does.
Specifically, it's the xorg.conf equivalent to XSetPointerMapping(3), it
doesn't do any physical button remappings, merely the logical ones. If the
physical button isn't mapped to the right logical button by default, that's
either a libiput bug or an xkcd 1172 issue.
X.Org Bug 90206 <http://bugs.freedesktop.org/show_bug.cgi?id=90206>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
No functional changes, though I did move a free() up a bit in the process (see
sendevents parsing).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
|
A client or xorg.conf setting may change the property but once changed it
cannot be reset by a client to the original state without knowledge about the
device.
Export the various libinput_...get_default() functions as properties.
https://bugs.freedesktop.org/show_bug.cgi?id=89574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
|
|
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
|
