Add xorg option ScrollFactor.
Add xinput option "libinput Scrolling Factor".
This works well in xi2 applications where they receive the raw scroll
value, however applications that use the core x11 protocol only for input
receive a scroll button press. The frequency this scroll button press
event is sent depends on the value of ScrollFactor, so it works in such
applications as well but the scrolling wont be as "smooth" as if they
used xi2.
gtk, qt, chromium (and electron) applications seem to use xi2 while
firefox does not, unless you set the MOZ_USE_XINPUT2=1 environment
variable.
Signed-off-by: dec05eba <dec05eba@protonmail.com>
Adds new properties and xorg.conf entries for setting the scroll acceleration
function's points and step.
The new xorg.conf entries are AccelPointsScroll, AccelStepScroll.
Adds new properties and xorg.conf entries for setting the acceleration
function's points and step.
`AccelProfile` option can now accept `custom` value.
Add 4 new options which only apply when `AccelProfile` is `custom`:
- Add `AccelPointsFallback` option for setting the points of the
Fallback acceleration function. Points values are represented by a
space-separated list, e.g. "0.0 1.0 2.4 2.5".
- Add `AccelStepFallback` option for setting the step of the Fallback
acceleration function. When a step of 0.0 is provided,
libinput default Fallback acceleration function is used.
- Add `AccelPointsMotion` and `AccelStepMotion` options, which are
equivalent to `AccelPointsFallback` and `AccelStepFallback` options,
but apply to the Motion acceleration function.
See libinput documentation for a detailed explanation of custom
pointer acceleration.
These don't change, iirc they exist because of some unixes having
different man pages but at this point really on Solaris is left and that
uses the same suffixes as everyone else.
And the __xservername__ is a leftover from the Xfree86 vs Xorg days - if
you're still running Xfree86, you're not using this driver.
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>
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>
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>
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>
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>
libinput always has horizontal scrolling enabled and punts the decision when
to scroll horizontally to the toolkit/widget. This is the better approach, but
while we have a stack that's not ready for that, and in the X case likely
never will be fully ready provide an option to disable horizontal scrolling.
This option doesn't really disable horizontal scrolling, it merely discards
any horizontal scroll delta. libinput will still think it's scrolling.
https://bugs.freedesktop.org/show_bug.cgi?id=91589
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
First, why is this here and not in libinput: drag lock should be implemented
in the compositor (not in libinput) so it can provide feedback when it
activates and grouped in with other accessibility features. That will work for
Wayland but in X the compositor cannot filter button events - only the server
and the drivers can.
This patch adds mostly the same functionality that evdev provides with two
options on how it works:
* a single button number configures the given button to lock the next button
pressed in a logically down state until a press+ release of that same button
again
* a set of button number pairs configures each button with the to-be-locked
logical button, i.e. a pair of "1 3" will hold 3 logically down after a
button 1 press
The property and the xorg.conf options take the same configuration as the
evdev driver (though the property has a different prefix, libinput instead of
Evdev).
The behavior difference to evdev is in how releases are handled, evdev sends
the release on the second button press event, this implementation sends the
release on the second release event.
https://bugs.freedesktop.org/show_bug.cgi?id=85577
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
With a long entry in the man page to detail what this option does.
Specifically, it's the xorg.conf equivalent to XSetPointerMapping(3), it
doesn't do any physical button remappings, merely the logical ones. If the
physical button isn't mapped to the right logical button by default, that's
either a libiput bug or an xkcd 1172 issue.
X.Org Bug 90206 <http://bugs.freedesktop.org/show_bug.cgi?id=90206>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
A client or xorg.conf setting may change the property but once changed it
cannot be reset by a client to the original state without knowledge about the
device.
Export the various libinput_...get_default() functions as properties.
https://bugs.freedesktop.org/show_bug.cgi?id=89574
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
This currently exposes the libinput button name, which isn't ideal. Needs to
be switched to X button numbers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
