This has never been supported through the stack. No device ever had the
required MOUSE_WHEEL_TILT_VERTICAL/HORIZONTAL udev property set, so
libinput never set the right axis source. Neither weston nor mutter
added the code for it. Even if we added wheel tilt for devices now, it
would break those devices. And the benefit we get from having those
separate is miniscule at best.
So let's do the long-term thing and just deprecate this axis source.
The wheel tilt mouse test device remains in the test suite, with the
udev properties set just to verify that we do indeed ignore those now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom Cintiq 24HD and later tablets send specific key events for
hardware/soft buttons. KEY_PROG1..KEY_PROG3 on earlier tablets,
KEY_CONTROLPANEL, KEY_ONSCREEN_DISPLAY, and KEY_BUTTONCONFIG on later tablets.
We ignore KEY_PROG1-3 because starting with kernel 5.4 older tablets will too
use the better-named #defines.
These differ from pad buttons as the key code in itself carries semantic
information, so we should pass them on as-is instead of mapping them to
meaningless 0-indexed buttons like we do on the other buttons.
So let's add a new event, LIBINPUT_EVENT_TABLET_PAD_KEY and the associated
functions to handle that case.
Pad keys have a fixed hw-defined semantic meaning and are thus not part of
a tablet mode group.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Scroll button locking is an accessibility feature. When enabled, the scroll
button does not need to be held down, the first click holds it logically down,
to be released on the second click of that same button.
This is implemented as simple event filter, so we still get the same behavior
from the emulated logical button, i.e. a physical double click results in a
single logical click of that button provided no scrolling was triggered.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is the public API only, not the internal bits, so nothing will work just
yet.
This interface addition is for the Dell Canvas Totem tool, so let's go with
the same name because options like "Rotary" are too ambiguous.
The totem is a knob that can be placed on the surface, it provides us with
location and rotation data. The touch major/minor fields are filled in by the
current totem, but they're always the same size.
The totem exports BTN_0 as well, so let's add that to the debug-events output.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Still not great and probably makes any professional designer's eyes bleed, but
at least it's more readable now.
Changes:
- spacing after param name so they don't cuddle up with the description
- color changes and background image removals to drop the doxygen default look
- font size changes to not make things overrun
- font family change to make the function prototypes readable
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is in preparation for a change to sphinx as the user-visible
documentation. Ideally we could cross-link between the two but that's tricky
to do automatically. Linking to the html pages/anchors directly works fine but
risks the links going stale, especially while the documentation is still in
flux.
Having a generic "refer to the libinput documentation" is a bit of a cop-out
least this way the links cannot go stale.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
So it shows up in the doxygen contents. These are the bits that are mostly of
interest to developers, we might remove the user documentation entry later,
but let's leave it there for now.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This looked good on paper but clearly no-one (including myself) ever tested this
in a real-life situation or they would've noticed that the constant factor is
missing, causing a segfault on the first two-finger scroll event, touchpad
gesture or button scrolling.
Adding the constant factor makes the API much worse and the benefit is
unclear, so out of the window it goes. We can revisit this for libinput 1.12
but this isn't going to make the next release.
This reverts commit d8bd650540.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This makes it possible for callers to detect whether a touch device is
single or multitouch (or even check for things like dual-touch vs real
multi-touch) and adjust the interface accordingly.
Note that this is for touch devices only, not touchpads that are just pointer
devices.
https://bugs.freedesktop.org/show_bug.cgi?id=104867
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This adds a third profile to the available profiles to map device-specific
speed to an acceleration factor, fully defined by the caller.
There has been a consistent call for different acceleration profiles in
libinput, but very little specifics in what actually needs to be changed.
"faster horses" and whatnot (some notable exceptions in e.g. bug 101139).
Attempts to change the actual acceleration function will likely break things
for others.
This approach opens up the profile itself to a user-specific acceleration
curve. A caller can set an acceleration curve by defining a number of points
on that curve to map input speed to an output factor. That factor is applied
to the input delta.
libinput does relatively little besides mapping the deltas to the
device-specific speed, querying the curve for that speed and applying that
factor. The curve is device-specific, the input speed is in device units/ms.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
doxygen ends the @bug command when a new section command (@code) is
encountered, leaving us with an "Example code:" on the Bug List page.
Add an empty line to cut off here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a leftover from when libinput was part of weston and we could
interpret properties correctly. Realistically, the only way this could work
with libinput as external library is if we define precisely what the
definition of an output is. Practically, it's a lot easier to just throw up
our hands and leave it all to the caller.
https://bugs.freedesktop.org/show_bug.cgi?id=100707
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This will allow switch devices known to libinput to be exposed. Currently,
this is SW_LID.
libinput also handles switch events internally, e.g. a laptop touchpad will
be disabled autmoatically when the lid is closed. This is transparent to
the caller, although the caller will also receive the event. See
https://bugs.freedesktop.org/show_bug.cgi?id=86223
This features is intended to be the main driver for the interface.
Co-Authored-By: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: James Ye <jye836@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The previously hardcoded button map for tapping is 1/2/3 to LRM. But the
middle button is a common feature on the desktop (used for paste, most
prominently) and three-finger tapping is almost impossible to do reliably on
some touchpads (e.g. the T440 has a recognition rate of ~1 in 5).
Left and right buttons have a prominent physical position (either softbuttons
or physical buttons) so make the tap order configurable. Those that require
middle buttons reliably can use the [software] buttons for left/right and
2-finger tap for a middle button.
https://bugs.freedesktop.org/show_bug.cgi?id=96962
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.
https://bugs.freedesktop.org/show_bug.cgi?id=96663
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Move mode control to libinput. This reduces some flexibility on what we can do
with modes but makes it a lot easier for anyone to implement modes correctly
and have the LEDs apply appropriately, etc. Let's go with the option to make
the 95% use-case easy. Note: whether the mode is actually used is up to the
caller, e.g. under Windows and OS X the mode only applies to the
rings/strips, not the buttons.
A tablet pad has 1 or more mode groups, all buttons/ring/strips are assigned
to a mode group. That group has a numeric mode index and is hooked to the
LEDs. libinput will switch the LEDs accordingly.
The mode group is a separate object. This allows for better APIs when it comes
to:
* checking whether a button/ring/strip is part of a mode group
* checking whether a button will trigger a mode transition
and in the future potentially:
* checking which mode transition will happen
* setting which button should change the mode transition
* changing what type of mode transition should happen.
* moving a button from one mode group to the other
This patch adds the basic scaffolding, without any real implementation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Proofread-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
They don't define anything, move them to the top so we don't have ordering
requirements of the stuff that actually uses those as parameters.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
Trackballs are effectively stationary devices and can be positioned at any
rotation. They are also employed by users with impaired dexterity which
sometimes implies that they are positioned at an non-default angle to make the
buttons easier to reach.
Add a config option for rotation for trackball devices. Currently only
supported for 90-degree angles, if there is a need we can add more angles
later.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
