xf86libinput.c:2457:89: warning: passing argument 1 of
‘libinput_event_pointer_get_axis_source’ from incompatible
pointer type [-Wincompatible-pointer-types]
No function changes due to the binary layout of libinput events but
let's not rely on that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86CheckStrOption returns the same value but doesn't mark it as used in
the server and, more importantly, doesn't spam the log with
(**) Option "_source" "server/udev"
messages.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Starting on libinput 1.19 pointer axis events have been deprecated in
favor of their scroll equivalents, including support for high-resolution
wheel scroll.
While it is recommended to handle the new events, some applications
and/or frameworks might not be ready at the moment.
Provide an option to discard high-resolution wheel scroll events.
Fix#41
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Where libinput supports high-resolution scroll events, the scroll source
is encoded in the event type.
Get the scroll source in xf86libinput_handle_event to facilitate the
migration.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This is just a number, to be used as divider and shouldn't have any effect in
correctly written clients. With the high-res scrolling coming up however, we
have a few devices where the dist cannot be expressed as an integer fraction
of 15, so let's up it to 120 because we know all hardware wheels have to be an
integer fraction of that that, thanks to Microsoft's API requirements.
For non-wheel scrolls we need to now map into the new range. Previously we
just passed the scroll events on from the touchpad/button scrolling, meaning a
vdist of 15 meant 15 "libinput pixels" of scrolling resulted in a logical
wheel click. Now that we have 120 as vdist, we need to times the input data by
8 to keep the same proportions.
See 39b0bb4585 for the previous revert.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To be used for touchpads and continuous (i.e. button-based scrolling).
libinput provides us with pixel data for finger-based and button-based
scrolling but the X server does support this - XI2.1 smooth scrolling is
merely centered around a logical scroll click (defined as "increment"), with
smooth scrolling being a fraction of that increment. For example, in the old
synaptics driver that value was in device-specific units and thus different
for every device.
The increment is a constant value set in the ScrollClass and cannot be changed
at device runtime. So we simply initialize with a random default (15, because
that works well for wheels) and then scale our pixel delta in to that range.
With the default value, a 15 pixel movement would result in a logical scroll
click, if the distance is set to 30 the users has to move 30 pixels to trigger
that scroll click. Pixel here being defined as the deltas that libinput
provides to us.
From the client's perspective nothing changes, the increment is still the
same.
Range checks are quite restrictive, this option is supposed to improve
usability, not as a workaround around other bugs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a touch input gets turned into a palm (by setting ABS_MT_TOOL_TYPE to
MT_TOOL_PALM), libinput will emit a cancel event instead of the normal
up event. The xorg wrapper needs to be able to handle a canceled touch
and lift it, otherwise these inputs will never get lifted and will stick
around forever.
Signed-off-by: Dorian Stoll <dorian.stoll@tmsp.io>
Add a boolean option/property to enable/disable the scroll button lock. Where
enabled, the button can be clicked and released as opposed to having to be
held down.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This merely tests against the devel package in Fedora, not against the xserver
from git. Should be enough, the driver here doesn't change enough to need the
git builds.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This bumps the required libinput version to 1.7 - which has been out for over
two years now. That's conservative enough.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was part of the high-resolution wheel work that was factored out ahead of
time. Problem is: this breaks scroll button emulation in the server as we
use the distance to determine when we click buttons 4-7.
Before: movement of 15 normalized pixel units on a touchpad - one click. Now:
120 of those units. So that's a bit less than ideal.
The change to 120 can be done, but needs the corresponding handling in the
axis distance calculations.
Fixes#24
This reverts commit 055481187d.
On devices with tools having both serial and id 0,
it would fail to create separate subdevices.
Thinkpad X220T (Wacom ISDv4 E6) now correctly registers
Pen and Eraser xinput devices.
This is just a number, to be used as divider and shouldn't have any effect in
correctly written clients. With the high-res scrolling coming up however, we
have a few devices where the dist cannot be expressed as an integer fraction
of 15, so let's up it to 120 because we know all hardware wheels have to be an
integer fraction of that that, thanks to Microsoft's API requirements.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The driver currently assumes that any wheel event has a non-zero discrete
value of 1. This is incorrect, it just hasn't triggered yet with any device.
With the hi-res scroll patches in place in the kernel and libinput, we may get
wheel events with a discrete value of 0. We assume that if this ever happens,
the device has some sensible click angle set so all we need to do is ignore
the discrete 0 events and wait for the first discrete event to come.
Also add an explanatory comment too to make it clear the calculation is only
done once.
Fixes#19
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is prep work for the hi-res work but right now, no real functional
changes. It does however fix a bug where we used the vertial scroll dist for
the horizontal wheel as well.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Users still like to copy the whole file, potentially messing things up.
Let's put a warning into the file directly that this is less than ideal.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Custom pointer acceleration curves were reverted in libinput, so no point
having this code here.
This reverts commit d84e0035d1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
One new property, and the existing accel profile gets extended to keep one
extra value. The new property libinput Accel Curve Points is a list of pairs
of points to be added to the acceleration curve.
libinput only supports adding points to the curve so we simply declare the
behavior as undefined when the curve is set multiple times. Also helps to
identify those that bother to read the man page before playing with random
driver values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For logind-setups we need to match the path libinput wants to open with the
Option Device path that the device has so we know when to return the
server-fd. This doesn't work for by-id or by-path because libinput resolves
those (through udev) to the actual eventX node so our paths look different
when they are the same device.
This could be fixed but since this is easy enough to work around with a
InputClass section and rather a niche case, it's not really worth the effort.
https://bugs.freedesktop.org/show_bug.cgi?id=105562
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Properties are initialized on the correct devices only but on resume we'd just
blindly apply the config from our device. Depending on the resume order, this
would mean we'd apply a previously set config with a default config.
Example:
* pointer device with keyboard subdevice
* pointer device exports natural scrolling, keyboard device does not and
remains at default (off)
* client enables natural scrolling on the pointer device
* VT switch away, VT switch back
* pointer device gets enabled first, enables natural scrolling on the
libinput device
* keyboard device gets enabled second, resets to the default value
Reported-by: Yuxuan Shui <yshuiv7@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Tested-by: Yuxuan Shui <yshuiv7@gmail.com>
87f9fe3a6fafe60134c6's intention was to not create properties that a subdevice
doesn't have configuration options for (i.e. if you have a pointer+keyboard
device, don't expose tapping configuration on the keyboard subdevice).
The result was messy, the checker function had a confusing triple-negation and
some properties weren't checked - e.g. left-handed was allowed for touch/tablet
but not for pointer, dwt was allowed for any device.
Fix this by moving the check into the property init function directly and
inverting the helper function to be easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Not all clients update the pointer position correctly from the button events
(for historical reasons) so we need to send a motion event before the button
event that represents a tip state change.
https://bugs.freedesktop.org/show_bug.cgi?id=101588
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If a device is split into multiple subdevices, usually pointer+keyboard, we
initialized properties matching the libinput device on both devices. This
results in the keyboard having e.g. a Accel Speed or Left Handed settings even
though it cannot send any events of that type.
Filter by capabilities on the subdevice so we only get those properties that
match the subdevice's capabilities.
https://bugs.freedesktop.org/show_bug.cgi?id=100900
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch splits the meat of xf86libinput_handle_tablet_axis into a helper
function xf86libinput_post_tablet_motion(), to be called right after we send
the proximity in event.
Clients that don't handle proximity (e.g. all XI2 clients) don't see the
coordinates we send along with the proximity events. And, for historical
reasons, they may not look at the coordinates in button events. So a device
that comes into proximity and immediately sends a tip down button event
doesn't send a motion event, causing the client to think the tip down was at
whatever the last known position was (before previous prox-out).
The practical effect is that when a user tries to draw a few dots, they end up
being connected to each other.
https://bugzilla.redhat.com/show_bug.cgi?id=1433755
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Caused by different results in -O0 vs -O2. The resulting array differs only
slightly but the initial sequence has one extra zero. That triggers our
assert, no other compiler flag seem to be affecting this.
Compiled with -O0:
Breakpoint 1, test_nonzero_x_linear () at test-bezier.c:157
157 assert(bezier[x] > bezier[x-1]);
(gdb) p bezier
$6 = {0 <repeats 409 times>, 1, 2, 4, 5, 7, 9, 10, 12, 14, 15, 17, 19, 21, 22,
Compiled with -O2:
(gdb) p bezier
$1 = {0 <repeats 410 times>, 1, 3, 5, 7, 9, 10, 12, 14, 15, 17, 19, 20, 22,
Printing of the temporary numbers in the decasteljau function shows that a few
of them are off by one, e.g.
408.530612/0.836735 with O0, but
409.510204/0.836735 with O2
Note: these are not rounding errors caused by the code, the cast to int
happens afterwards.
Hack around this by allowing for one extra zero before we check that the rest
of the curve is ascending again.
https://bugs.freedesktop.org/show_bug.cgi?id=99992
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Only use-case here are pad mode LEDs that now live in /sys/class/leds. Asking
the server to open them is pointless, the server only knows how to open Option
"Device". And since the LEDs are in sysfs we should have access to them
anyway, so no need for jumping through or hula-ing hoops.
xf86CloseSerial() works as intended as it's a slim wrapper around close(), so
we only have to worry about the open() path here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Updating the property directly causes us to send events from the input thread
which has some "interesting" side effects like messing up the reply order or
just crashing the server.
Schedule a work proc instead and update it whenever the server is back in the
main thread.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
By default, the X server maps the tablet axes to the available screen area.
When a tablet is mapped to the screen but has a different aspect ratio than
the screen, input data is skewed. Expose an area ratio property to map the
a subsection of the available tablet area into the desired ratio.
Differences to the wacom driver: there the x/y min/max values must be
specified manually and in device coordinates. For this driver we merely
provide the area ratio (e.g. 4:3) and let the driver work out the rest.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Takes a 4-point cubic bezier curve as input and maps the pressure coordinates
to the values outlined by this curve. This is an extension of the current
implementation in the xf86-input-wacom driver which only allows the two center
control points to be modified.
Over the years a few users have noted that the wacom driver's pressure curve
makes it impossible to cap the pressure at a given value. Given our bezier
implementation here, it's effectively a freebie to add configurability of the
first and last control points. We do require all control points' x coordinates
to be in ascending order.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For a mouse with a click angle of 15 degrees things are unchanged. For devices
with angles less than 10, the current code scrolled way too fast. Because the
angle wasn't used anywhere, each tick would count as full scroll wheel event,
a slight movement of the wheel would thus scroll as much as a large movement
on a normal mouse.
Fix this by taking the actual click angle of the device into account. We
calculate some multiple of the angle that's close enough to the default 15
degrees of the wheel and then require that many click events to hit the full
scroll distance. For example, a mouse with a click angle of 3 degrees now
requires 5 clicks to trigger a full legacy scroll button event.
XI2.1 clients get the intermediate events (i.e. in this case five times
one-fifth of the scroll distance) and can thus scroll smoothly, or more
specifically in smaller events than usual.
https://bugs.freedesktop.org/show_bug.cgi?id=92772
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Changed this during development because I forgot that the value actually
matters (for touchpads anyway).
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If an XKB AccessX timeout is set and a VT switch is triggered, the
AccessXTimeoutExpire function may be called after the device has already been
disabled. This can cause a null-pointer dereference as our shared libinput
device may have been released by then.
In the legacy drivers this would've simply caused a write to an invalid fd
(-1), not a crash. Here we need to be more careful.
https://bugs.freedesktop.org/show_bug.cgi?id=98464
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The parent device ref's the libinput device during pre_init and unref's it
during DEVICE_INIT, so the copy is lost. During DEVICE_ON, the libinput device
is re-added and ref'd, this one stays around now. But the takeaway is: unless
the device is enabled, no libinput device reference is available.
If a device is a mixed pointer + keyboard device, a subdevice is created
during a WorkProc. The subdevice relied on the parent's libinput_device being
available and didn't even check for it. This WorkProc usually runs after
the parent's DEVICE_ON, so in most cases all is well.
But when running without logind and the server is vt-switched away, the parent
device only runs PreInit and DEVICE_INIT but never DEVICE_ON, causing the
subdevice to burn, crash, and generally fail horribly when it dereferences the
parent's libinput device.
Fix this because we have global warming already and don't need to burn more
things and also because it's considered bad user experience to have the
server crash. The simple fix is to check the parent device first and if it is
unavailable, create a new one because it will end up disabled as well anyway,
so the ref goes away as well. The use-case where the parent somehow gets
disabled but the subdevice doesn't is a bit too niche to worry about.
This doesn't happen with logind because in that case we don't get a usable fd
while VT-switched away, so we can't even run PreInit and never get this far
(see the paused fd handling in the xfree86 code for that). It can be
reproduced by setting AutoEnableDevices off, but why would you do that,
seriously.
https://bugs.freedesktop.org/show_bug.cgi?id=97117
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The property is tablet-wide, not just per tool. So when one tool is updated,
run through all other devices that share the same underlying device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Now that we sort below the xf86-input-wacom driver anyway, there's no good
reason to ignore tablets anymore.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
is_libinput_device(next) causes a dereference of next anyway, so this cannot
ever be NULL.
Besides, if next ends up as NULL that means we have lost count of how many
remaining devices use libinput, so we have other issues.
Found by coverity.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(),
the thread eventually calls read_input on a struct that has been deleted.
Avoid this by swapping out the to-be-destroyed pInfo with the first one we
find.
Reproducer: sudo udevadm trigger --type=devices --action=add
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
If --prefix isn't specified on the command line, $prefix contains "NONE"
at this point, not the default prefix value. So make install would
attempt to install the xorg.conf.d snippet to
${DESTDIR}NONE/share/X11/xorg.conf.d/.
Avoid this by leaving ${prefix} verbatim in the default value, to be
resolved by make.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looks like a cut&paste coding error to me, and it generated a
compiler warning about possibly uninitialized value.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Clear typo. Not bothering to be backwards compatible here, anything that uses
the #define will update on rebuild, anyone using the string directly should've
told me about the typo...
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Avoid creating new devices from within the input thread which was the case for
tablet tools. It requires a lot more care about locking and has a potential to
mess up things.
Instead, schedule a WorkProc and buffer all events until we have the device
created. Once that's done, replay the event sequence so far. If the device
comes into proximity and out again before we manage to create the new device
we just ditch the whole sequence and wait for the next proximity in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the continuation of 3f569ec493, dropping libinput below the remaining
drivers. Wacom and synaptics already sort higher anyway (see wacom commit
0da5cd54 and synaptics commit 59e5db025). evdev remains the catchall
basic fallback driver and is overwritten by libinput. The two drivers affected
by this patch are joystick and vmmouse.
joystick is a niche driver and drives devices libinput doesn't handle anyway
so there is no need to override. If a user installs it, presumably it is to
use it.
vmmouse is a niche driver and does not assign itself anymore for newer kernel
drivers (see vmmouse commit 576e8123 from Oct 2014). So if vmmouse is
installed it can safely sort higher than libinput.
Note: this is upstream behavior, distributions have to work out the wanted
behavior themselves by renaming the config snippets accordingly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
There is not good wire protocol for pad modes so instead we just export the
information via properties. One property to tell us how many groups and how
many modes each group has. One property for the current mode of each group.
And three properties to tell us which group each button, ring and strip is in.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The list returned by xf86FirstLocalDevice() includes our own device. If the
parent device is removed before the hotplug callback is invoked, the first
match with the same shared-device ID is our own device (or potentially another
subdevice on the same already-removed parent). Avoid this by making sure the
matched device is actually a parent device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Keith Packard <keithp@keithp.com>
If the parent device is removed before the WorkProc is called, the private
data is NULL.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
libinput can't run at SIGIO time, so it has been using
AddEnabledDevice to run in non-signal context.
Threaded input runs all input in non-signal context, so we want to use
xf86AddEnabledDevice at last.
v2: use XINPUT ABI version check instead of testing for presence of
AddEnabledDevice, which can't get removed from the server until
a few more patches past the threaded input change are merged.
v3: remove reference to XI86_SIGNAL_IO, which was presumably
a planned change to the xf86AddEnabledDevice path to make that
not use SIGIO.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Two bugs caused proximity events to be discarded. First, on proximity out
posting through pDev would be discarded because pDev is the parent device that
we use as a base for hotplugging the real devices for each tool from. That
device never sends events though, doing so will see the event discarded in the
server.
Second, if the tool already exists don't just exit, send the proximity event
first. To unify the three paths where we do send the events simply move them
down to the exit phase of the function.
https://bugs.freedesktop.org/show_bug.cgi?id=95484
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Modelled to be mostly compatible to the xf86-input-wacom driver behavior. The
pad gets 7 axes, the first three of which are mute and the others are always
available but obviously only send events when the axis is there.
The strip axes are incompatible, the wacom driver merely forwards the device
events (which are a bitshifted value), libinput normalizes it and we just
expand this back into an integer range. Let's see how we go with this.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
60 sorts higher than the other drivers (evdev has 10, synaptics, wacom and
others have 50) so we keep the same order.
This is part of a two-step solution, the other half is renaming the
xf86-input-wacom's config snippet to sort higher than libinput's.
Currently libinput picks up devices that are (for now) destined to the wacom
driver. Since the wacom driver is more of a leaf package than libinput, the
best option here is to make the wacom driver sort higher and let users
uninstall it when not needed. To avoid crowding the 90-* space where users
usually have custom config snippets, drop libinput down to 60 and bump wacom
up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
Use two new internal capabilities, CAP_TABLET and CAP_TABLET_TOOL. If a
libinput tablet device is added, add an X device without any classes. This
device will not send events, but once we have pad support in libinput we
may be able to this the pad device.
When a tool comes into proximity, create a new X device for that serial number
and start sending events through it. Since the X device only represents a
single serial number/type combination, some of the wacom-specific
configuration options fall away. This only matters in the case of multiple
tools, in which case a per-tool configuration is preferable anyway, so we
don't lose anything here.
Gesture support only applied to the touch parts on the device, we don't
deal with this here specifically - that event node is handled by libinput as
touchscreen or touchpad.
This already works with GIMP and clients that don't rely on any
wacom-driver-specific properties. Configuration clients like
gnome-settings-daemon will need to change to handle new properties, to be
added as we go along.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This splits the hotplugging code up so we can use it through a callback but
also as an immediate call that gives us back the device just hotplugged. Also
added is the ability to add extra options to the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure we don't send any events that may have been enqueued before we
initialized ourselves. Specifically, if we're using systemd-logind the fd
remains open when we disable/enable the device, allowing events to queue up on
the fd. These events are then replayed once the device is re-opened.
This is not the case when VT-switching, in that case logind closes the fd for
us.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-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=49950https://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 c943739a2b.
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=49950https://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>
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>
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>
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>
* Permission to use, copy, modify, distribute, and sell this software
* and its documentation for any purpose is hereby granted without
* fee, provided that the above copyright notice appear in all copies
* and that both that copyright notice and this permission notice
* appear in supporting documentation, and that the name of Red Hat
* not be used in advertising or publicity pertaining to distribution
* of the software without specific, written prior permission. Red
* Hat makes no representations about the suitability of this software
* for any purpose. It is provided "as is" without express or implied
* warranty.
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to
* deal in the Software without restriction, including without limitation the
* rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
* sell copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
* NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
* OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
* NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
* IN THE SOFTWARE.
*/
#include"draglock.h"
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
