We use 2 mechanisms to unregister the trackpoint event listener depending on
device removal order.
1) We have a device_removed callback, if the trackpoint gets removed before
the touchpad, this gets called, sees the device being removed is the trackpoint
and unregisters the listener
2) If the touchpad gets removed first, then in tp_destroy we unregister the
listener
2) May be delayed beyond the destruction of the trackpoint itself if the
libinput user has a reference to the libinput_device for the touchpad.
When this happens the trackpoint still has an eventlistener at destroy time
and an assert triggers.
To fix this we must do 2) at the same time as we do 1), so at remove time.
While working on this I noticed that the touchpad code was also cancelling
timers at destroy time rather then remove time, which means that they may
expire between remove and destroy time, and cause events to be emitted from
a removed device, so this commit moves the cancelling of the timers to the
remove callback as well.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Some dispatchers may want to do some cleanup at remove time, rather then at
destroy time.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Fixes a crash if the LIBINPUT_CALIBRATION_MATRIX is set for a relative device.
https://bugs.freedesktop.org/show_bug.cgi?id=86993
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Fixes distcheck (automake 1.14.1)
make[2]: Entering directory '....../libinput-0.7.0/_build/test'
Makefile:926: ../src/.deps/libinput-util.Plo: No such file or directory
make[2]: *** No rule to make target '../src/.deps/libinput-util.Plo'. Stop.
make[2]: Leaving directory '....../libinput/libinput-0.7.0/_build/test'
Makefile:412: recipe for target 'distclean-recursive' failed
That was the only place we used subdir objects, so we can drop it from
configure now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
For certain applications (such as FPS games) it is necessary to use
unaccelerated motion events (the motion vector that is passed to the
acceleration filter) to get a more natural feeling. Supply this
information by passing both accelerated and unaccelerated motion
vectors to the existing motion event.
Note that the unaccelerated motion event is not equivalent to 'raw'
events as read from devices.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Always check for invalid input first, then check if the input is supported by
the actual device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Allow retrieval of the libinput context from the seat and the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The libinput device abstracts a number of things but sometimes the underlying
device is important. The udev device provides the necessary handle to access
that underlying device and various sysfs properties that may be necessary.
A function returning the device node would've done the same thing but is more
prone to race conditions than the udev_device.
https://bugs.freedesktop.org/show_bug.cgi?id=85573
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
400 used to be the default DPI for many mice but it it's not anymore. A survey
of mice shows that 400 is still common as one of the pre-configured settings
in switchable multi-resolution gaming mice, but devices with a single
resolution mostly favor 1000 dpi.
Let's make that switch now so that any future changes to the pointer
acceleration code assumes that resolution as a default.
For the touchpad, this has a bad side-effect, caused by our expectation of
mouse vs touchpad behaviours: our acceleration code ignores device type and
provides the same acceleration for the same physical movement. Unfortunately,
we expect touchpads to be significantly slower than mice.
The previous 400 DPI worked because it caused an acceptable slowdown on input.
e.g. on the T440 with a res of 42 units/mm, the scale coefficient was 0.37.
For 1000 DPI as default, this now results in 0.94, i.e. speeding up the
touchpad by a factor of 2.5. That is way too fast.
Adding touchpad-specific filter code is a bigger project, so let's just add a
fixme for now and scale the coefficient back to what it was before the
DPI default change. Effect: touchpad behaves as before.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The filter code is what relies on some default dpi configuration to apply
pointer acceleration and expects the input coordinates to be pre-scaled to
that resolution.
Let's move the define here so we can use it from the touchpad code too.
No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of using a hard coded mouse DPI value, we query it from udev.
If it's not present or the property is obviously broken we fall back
to default.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
The early exit path in evdev_device_compare_syspath() expects
udev_device_new to be initialized to NULL, but it wasn't.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This patch allows libinput to ignore devices that have joystick buttons.
Signed-off-by: Krzysztof Sobiecki <sobkas@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add edge-scrolling support for non multi-touch touchpads as well as for
users who prefer edge-scrolling (as long as they don't have a clickpad).
Note the percentage to use of the width / height as scroll-edge differs from
one manufacturer to the next, the various per model percentages were taken
from xf86-input-synaptics.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=85635
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is useful to know in some cases, it is e.g. necessary to figure out
which percentage of a touchpads range to use as edge for edge-scrolling.
Note this is a slightly cleaned up copy of the same code in
xf86-input-synaptics.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is purely a code move, this is a preparation patch for adding edge
scrolling support.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The seat of a device is currently immutable, but a device may (in a
multi-pointer case) move between different logical seats. Moving it between
seats is akin to removing it and re-plugging it, so let's do exactly that.
The physical seat name stays immutable.
Pro:
- device handling after changing a seat remains identical as handling any
other device.
Con:
- tracking a device across seat changes is difficult
- this is not an atomic operation, if re-adding the device fails it stays
removed from the original seat and is now dead
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prep work for changing seat names on devices. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Prep work for changing seat names on devices. No functional changes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Potential race condition:
- udev notifies us that a udev_device became available
- we go for a coffee and chat to the neighbours on the way
- the device is unplugged
- a new device is plugged in, gets the same devnode
- we finish our coffee and come back
- open(udev_device_get_devnode())
- new device is now opened as the old device
To avoid the above race, we compare the syspath of the device at the open fd
with the syspath of the device we originally wanted. If they differ, we fail.
evdev_compare_syspath was simply moved up.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Using a udev_device instead of the various bits separately safes us
re-initializing udev contexts whenever we need to compare the device. And
having the actual udev device makes it a bit easier to ensure that we're not
re-initializing a different device as a current one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Long-term plan to use more of udev_device here is to better protect us against
re-opening a different device that happens to have the same devnode.
This now also prints an error message for invalid devices, the log tests are
adjusted.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We need it for each device anyway, keep the ref around. Makes error handling a
bit easier, we don't need to handle failing udev_new() and reduce the danger
of mis-refcounting it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
We're about to add natural scroll support to other devices as well, let's
share the code.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This effectively disables the button scrolling, but since 0 is the default
button for most devices, we should allow setting the default button.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Default to 2fg scrolling for now, once we have edge-scrolling we can default
to edge-scrolling on touchpads which cannot detect more than 1 touch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
To avoid confusion with scroll mode configuration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Keep the default behavior of middle button scrolling on trackpoints, this
allows turning off middle button scrolling on trackpoints, as well as turning
on button scrolling on trackballs.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=85535
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a configuration option to allow selecting between 2-finger / edge / none
scrolling (for touchpads).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
In some cases the compositor will want to know which buttons a device has.
E.g. for scrolling we want the compositor to be able to set a button to change
a relative device (e.g. a trackball) into scroll mode, so that it sends
scroll-axis events instead of pointer motion events.
In order for the compositor to be able to present a sane UI for this, it needs
to know which buttons a device has.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Fix libinput_device_config_send_events_get_default_mode docs referring to
itself, instead make it refer to libinput_device_config_send_events_get_mode.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previous code used delta/event as scroll trigger which roughly translates
to speed, but depends on the sampling rate of the device.
For slow two-finger motion, a user may move the height of the touchpad without
ever triggering scrolling. Change the _initial_ trigger to a cumulative
trigger, i.e. once the user moved past the threshold distance, scrolling
starts regardless of the speed.
Once scrolling is engaged, the original trigger of threshold/event is
required to engange the second scroll direction.
Note that except for really slow movements, it's very easy to engage both
scroll directions on a touchpad. This is intentional, libinput does not have
enough semantic knowledge to know if horizontal scrolling is needed. So we
provide some direction locking but not much, it's up to the
client/toolkit/widget to decide if both scroll directions should be handled.
Add a comment to clarify that in the public doc.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
