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>
It's a bit hard to find what can be configured in the wall of text that is the
doxygen output. Add a TOC of the various options so it's easy to get a quick
grasp.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This interface handles the buttons on the physical tablet itself, including
the touch ring and the strip.
A notable difference to other libinput interfaces here is that we do not use
linux/input.h event codes for buttons. Instead, the buttons are merely
numbered sequentially, starting at button 1. This means:
* the API is different, instead of get_button() we have get_button_number() to
drive the point home
* there is no seat button count. pads are inherently different devices and
compositors should treat them as such. The seat button count makes sense
when you want to know how many devices have BTN_LEFT down, but it makes no
sense for buttons where all the semantics are handled by the compositor
anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Carlos Garnacho <carlosg@gnome.org>
The newer Cintiqs have a minimum value of 400/400 advertised by the kernel but
the actual sensor goes past the 0/0 origin. Test this, make sure that a value
outside the boundaries generates negative mm values.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The Wacom tilt range is 64 degrees so we map everything into that until we
know otherwise.
This commit also switches the tilt axes around to align the angles with the
x/y orientation, i.e. tilting the top of the stylus towards the positive x
axis now generates a positive x tilt.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jason Gerecke <jason.gerecke@wacom.com>
There are a number of use-cases where tapping may be desirable, but
tap-and-drag is not, e.g. where tapping is used to select multiple items in a
list. Having tap-and-drag on hinders this, and the nature of the interaction
means it cannot be detected based on timeouts, movement thresholds, etc.
Provide an option instead to turn tap-an-drag off. Tap-and-drag remains
enabled by default (though tapping is disabled by default).
For the touchpad tap state diagram, the new option disables the transition
from state TOUCH to state TAPPED and releases the button immediately instead.
This means that multitap-and-drag is disabled too since we now just loop
around in the single-tap state for multitap.
It also makes tapping more responsive - we don't have to wait for the timeout
before we know whether it's a tap event. The first touch time is noted, we now
send the button press with the time of the first touch and the release with
the time of the release. This ensures a realistic time diff between the two
events.
https://bugs.freedesktop.org/show_bug.cgi?id=93502
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.netto>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Instead of an explicit tablet mode that device must be changed into, let the
caller decide which coordinates are preferred. The tablet mode may be
application-specific and usually depends on the tool as well.
This patch adds an interface to get a motion delta for the x/y axes in
pixel-like coordinates. libinput provides some magic to convert the tablet
data into something that resembles pixels from a mouse motion.
For unaccelerated relative motion, the caller should use the mm values from
the tablet and calculate deltas manually.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
There's no reason to prevent this for button events. Unlike the pointer
which is a relative device a tablet is (usually) a device with a lot of state.
Caller code that handles axes is likely shared between the various events,
treating button events separately here doesn't get us any benefit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Jason Gerecke <jason.gerecke@wacom.com>
