Since our API doesn't accomodate for "dunno" we need to pick a mode that
we are actually in. This happens on the Intuos Pro 2 (PTH-660) which has
all LEDs on brightness zero, resulting in a failure to set up the modes
and we're left without a mode button.
Fix it by just picking zero as the default mode until specified
otherwise.
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1069>
Some tablets such as those in the XP-PEN PRO series use "dials" which
are actually scrollwheels and emit EV_REL events. These should not be
emulated as rings (which are absolute) so we must expose them as a new
tablet event.
Adds LIBINPUT_EVENT_TABLET_PAD_DIAL that work largely identical as our
high-resolution wheel events (i.e. the values are in multiples or
fractions of of 120). Currently supports two dials.
This is a lot of copy/paste from the ring axes because the interface is
virtually identical. The main difference is that dials give us a v120
value in the same manner as our scroll axes.
Notes:
- REL_DIAL is mutually exclusive with REL_WHEEL, we assume the kernel
doesn't (at this point) give us devices with both. If this changes for
devices with three dials (wheel + hwheel + dial) we need to add code
for that.
- REL_DIAL does not have a high-resolution axis and we assume that any
device with REL_WHEEL_HI_RES will also have REL_HWHEEL_HI_RES (if the
second wheel exists).
- With dials being REL_DIAL or REL_WHEEL there is no possibility of
detecting a finger release (the kernel does not route EV_RELs with a
value of zero). Unless this is implemented via a side-channel - and it
doesn't look like any hardware that supports dials does that - we
cannot forward any information here. So unlike absolute rings we
cannot provide a source information here.
Closes#600
Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net>
Part-of: <https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/967>
We don't want the file to be left open after any fork/exec, and we don't
want the read to be blocking; so open it as such.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
No real changes for the non-tablet code, but for tablets we now keep the
libwacom datbase around. The primary motivating factor here is response time
during tests - initializing the database under valgrind took longer than the
proximity timeouts and caused random test case failures when a proximity out
was triggered before we even got to process the first event.
This is unfortunately a burden on the runtime now since we keep libwacom
around whenever a tablet is connected. Not much of an impact though, I
suspect, chances are you're running a web browser and everything pales against
that anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Use the same blurb everywhere, changing from the old style MIT to the Expat
license we're using everywhere else.
Similar to bc9f16b40e
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's no guarantee that libinput does the right thing if memory allocation
fails and it's such a niche case on the systems we're targeting that it just
doesn't matter. Simply abort if zalloc ever fails.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Prefix device log messages with the device's sysname so it's more obvious
where the messages are coming from. This makes it much easier to grep for a
specific device's messages but also adds some identifier to messages that
were previously without any identifier (e.g. all the state machine debugging)
All info and error messages also automatically prefix the device name, so
those messages are standardised too, e.g
an info message now:
event4 - SynPS/2 Synaptics TouchPad: is tagged by udev as: Touchpad
a debug message now:
event4 - using pressure-based touch detection
And since this required changing a lot of the strings in messages anyway,
polish a few minor things too.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Hans de Goede <hdegoede@redhat.com>
We don't init the required /sysfs files, so let's not spew a lot of warnings
during the test suite.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
For each device open the various led devices (brightness only) and map the one
nonzero brightness to the current mode.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Until the kernel patches to handle LED group switching are in place we provide
the external API backed by an implementation that simply exposes one group
with one mode and no toggle buttons. This allows us to ship a libinput release
with the API in place and switch libinput later without having all the stack
above us being delayed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>