> /builds/metux/xf86-input-libinput/_builddir/../src/xf86libinput.c:2617:9: warning: enumeration value 'LIBINPUT_EVENT_TABLET_PAD_KEY' not handled in switch [-Wswitch]
> 2617 | switch (type) {
> | ^~~~~~
> /builds/metux/xf86-input-libinput/_builddir/../src/xf86libinput.c:2617:9: warning: enumeration value 'LIBINPUT_EVENT_GESTURE_HOLD_BEGIN' not handled in switch [-Wswitch]
> /builds/metux/xf86-input-libinput/_builddir/../src/xf86libinput.c:2617:9: warning: enumeration value 'LIBINPUT_EVENT_GESTURE_HOLD_END' not handled in switch [-Wswitch]
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
> /builds/metux/xf86-input-libinput/_builddir/../src/xf86libinput.c: In function 'xf86libinput_set_pressure_range':
> /builds/metux/xf86-input-libinput/_builddir/../src/xf86libinput.c:465:53: warning: declaration of 'range' shadows a global declaration [-Wshadow]
> 465 | const struct range *range)
> | ~~~~~~~~~~~~~~~~~~~~^~~~~
> In file included from /usr/include/xorg/xf86.h:44,
> from /builds/metux/xf86-input-libinput/_builddir/../src/xf86libinput.c:36:
> /usr/include/xorg/xf86str.h:110:3: note: shadowed declaration is here
> 110 | } range;
> | ^~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only consumer already properly checking for NULL return value,
so can directly use calloc() here, instead of zalloc() which is
crashing the Xserver.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Build of input-libinput fails on GCC-11.2 although succeeds on GCC-14.2.
Function vasprintf() becomes implicitle declared because its definition
in stdio.h is guarded by __GLIBC_USE_LIB_EXT2 which depends on _USE_GNU,
which in turn depends on __GNU_SOURCE. __GNU_SOURCE is defined at
the beginning of util_string.h before #include <stdio.h>, and this file
is included by util_strings.c and xf86libinput.c. The latter file
includes first a lot of headers in /usr/include and /usr/include/xorg,
and finally util_string.h. If some of the previous header files
#include <stdio.h>, then it is included first without _GNU_SOURCE, and
vasprintf() is left undefined, which causes a build error.
This patch moves #define _GNU_SOURCE to util_strings.c and xf86libinput.c
from util_strings.h, thus making vasprintf() declaration safe and
independent of a specific compiler.
Signed-off-by: Oleh Nykyforchyn <olen.nyk@gmail.com>
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>
Unsed code and just making trouble on correctly including stdio.h, because
it's using a GNU extension function -- vasprintf().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Unsed code and just making trouble on correctly including stdio.h, because
it's using a GNU extension function -- vasprintf().
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
../src/xf86libinput.c: In function ‘prop_draglock_set_pairs’:
../src/xf86libinput.c:5153:30: warning: comparison is always false due to limited range of data type [-Wtype-limits]
5153 | if (pairs[i] > MAX_BUTTONS)
MAX_BUTTONS is defined by the server so let's use a temporary local
variable to silence the compiler.
Part-of: <https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/merge_requests/61>
This now warns on 64-bit machines:
../src/xf86libinput.c:542:61: warning: format ‘%lu’ expects argument
of type ‘long unsigned int’, but argument 4 has type ‘CARD32’ {aka ‘unsigned int’} [-Wformat=]
Given they vastly outnumber 32-bit machines now, let's go back to the
old one that only warns on 32 bit until we fix the actual source types
to use uint32_t and similar.
This reverts commit a7d2994256.
Latest master moved the BUG_() macros out of os.h, and it's more appropriate
to use xf86IDrvMsg() in those cases (like we're already doing in other places)
anyways.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The driver encodes the serial in the device name but that's not reliable
enough. Expose both serial and tool id (optional) as a property so
clients can read them and adjust their behavior accordingly.
Fixes#16
Buttons 4-7 are out of bounds for hysterical historical reasons.
Previously this button fell through to the default statement and
resulted in 8 + BTN_STYLUS3 - BTN_SIDE == 65 which is rather obviously
wrong.
Instead, map it explicitly to what the fourth button would be mapped to
on other devices. This will now overlap with BTN_SIDE on devices that
both BTN_STYLUS3 *and* BTN_SIDE but those devices don't appear to exist
in the real world.
Fixes#50
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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.
xf86libinput.c:2457:89: warning: passing argument 1 of
‘libinput_event_pointer_get_axis_source’ from incompatible
pointer type [-Wincompatible-pointer-types]
No function changes due to the binary layout of libinput events but
let's not rely on that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
xf86CheckStrOption returns the same value but doesn't mark it as used in
the server and, more importantly, doesn't spam the log with
(**) Option "_source" "server/udev"
messages.
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>
Where libinput supports high-resolution scroll events, the scroll source
is encoded in the event type.
Get the scroll source in xf86libinput_handle_event to facilitate the
migration.
Refactor, no functional changes.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
This is just a number, to be used as divider and shouldn't have any effect in
correctly written clients. With the high-res scrolling coming up however, we
have a few devices where the dist cannot be expressed as an integer fraction
of 15, so let's up it to 120 because we know all hardware wheels have to be an
integer fraction of that that, thanks to Microsoft's API requirements.
For non-wheel scrolls we need to now map into the new range. Previously we
just passed the scroll events on from the touchpad/button scrolling, meaning a
vdist of 15 meant 15 "libinput pixels" of scrolling resulted in a logical
wheel click. Now that we have 120 as vdist, we need to times the input data by
8 to keep the same proportions.
See 39b0bb4585 for the previous revert.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
