libinput issueshttps://gitlab.freedesktop.org/libinput/libinput/-/issues2023-12-19T04:15:08Zhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/955High polling rate mouse using USB 3 moves twice or more as fast as it should.2023-12-19T04:15:08ZRandom ValueHigh polling rate mouse using USB 3 moves twice or more as fast as it should.## Summary
Originally coming from a Reddit [thread](https://www.reddit.com/r/MouseReview/comments/187pzuz/pulsar_xlite_v2_vs_xlite_v3_dpi_difference/), I was able to track down the problem to libinput.
I confirm that the problem is onl...## Summary
Originally coming from a Reddit [thread](https://www.reddit.com/r/MouseReview/comments/187pzuz/pulsar_xlite_v2_vs_xlite_v3_dpi_difference/), I was able to track down the problem to libinput.
I confirm that the problem is only when I launch Hyprland; when I am using X11 or Windows 10, everything is fine. How can the mouse sensitivity be different? In the Hyprland configuration file, I have disabled the mouse acceleration (`= 0` there).
In Hyprland, when the [input.force_no_accel](https://wiki.hyprland.org/Configuring/Variables/#input) is set to `true`, both mice move the same, which is correct. They also move the same way, with the acceleration profile being "flat", however, I prefer not to have any acceleration at all. Note that by default, Hyprland uses this acceleration profile: `libinput_device_config_accel_get_default_profile(LIBINPUTDEV))` and it seems to cause the trouble.
The 1000 hz+ capable mouse with 1600 DPI, currently running at 4000 hz:
```plaintext
T: Bus=05 Lev=01 Prnt=01 Port=03 Cnt=04 Dev#= 5 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=484d ProdID=1002 Rev= 1.12
S: Manufacturer=HeatMoving
S: Product=Pulsar Dongle
C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 11 Ivl=250us
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
```
The 1000hz-only mouse with 1600 DPI:
```plaintext
T: Bus=09 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=25a7 ProdID=fa7c Rev=13.32
S: Manufacturer=Compx
S: Product=Pulsar Xlite Wireless
C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 98mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 7 Ivl=1ms
I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=01 Driver=usbhid
```
To clarify the problem and summarise, every single mouse, given the same polling rate and the same DPI, must move equally, which is not the case. Setting the "flat" acceleration profile or using Hyprland's trick to use the unaccelerated values from Wayland solves the issue, but this is not a real solution and should never be: the solution for a user would be if libinput handled such situations correctly without any configuration if it is not required (and in this case, as far as I can judge, it isn't).
If you have an idea of where one might look to fix this within the code base, please feel free to share; I might get it done if I have time myself.
## Steps to reproduce
Just have a mouse capable of supporting more than 1khz polling rate, and use Wayland (on X11, everything is great).
## Required information
- libinput version: 1.24.0
- hardware information: AMD 7950x3d, 64GB DDR5 6000mhz.
- `libinput record` output:
[pulsar-xlite-v3-4khz](/uploads/090652e8beb87b38c550c367bb5c57e7/pulsar-xlite-v3-4khz)
[pulsar-xlite-v2-1000hz](/uploads/de78986ee6ddd8ed300d0f20e59e0bfd/pulsar-xlite-v2-1000hz)
- `libinput debug-events --verbose` output:
[out](/uploads/21f6e41346a05931a834d3cd66111141/out)https://gitlab.freedesktop.org/libinput/libinput/-/issues/909Clickfinger button mapping cannot be changed (but tapping can)2023-12-19T04:25:55ZPeter HuttererClickfinger button mapping cannot be changed (but tapping can)Brought up in https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/898#note_1956174 by @marcan
We can `libinput_device_config_tap_set_button_map()` so that 2fg tap is middle and 3fg tap is right, but we cannot do the same f...Brought up in https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/898#note_1956174 by @marcan
We can `libinput_device_config_tap_set_button_map()` so that 2fg tap is middle and 3fg tap is right, but we cannot do the same for the clickfinger method, leading to the odd case that a 2fg interaction does something different with tap vs click. Not ideal though afaik we've never had a bug filed about that.
Ideally we have a similar config call to apply the same mapping to clickfinger.https://gitlab.freedesktop.org/libinput/libinput/-/issues/894Cursor jumps on Ctrl + Tap on Dell Inc. Latitude 5500 touchpad2024-01-12T22:45:42ZPavilufCursor jumps on Ctrl + Tap on Dell Inc. Latitude 5500 touchpad## Summary
Cursor jumps on Ctrl + Tap on Dell Inc. Latitude 5500 touchpad
## Steps to reproduce
Make some Ctrl + Tap on Dell Inc. Latitude 5500 touchpad for the problem to happen
## Required information
- libinput version: Version: ...## Summary
Cursor jumps on Ctrl + Tap on Dell Inc. Latitude 5500 touchpad
## Steps to reproduce
Make some Ctrl + Tap on Dell Inc. Latitude 5500 touchpad for the problem to happen
## Required information
- libinput version: Version: 1.20.0-1ubuntu0.2
- hardware information: Dell Inc. Latitude 5500 touchpad
- `libinput record` output: [touchpad.yml](/uploads/5bb4980f3598406d974b4c6d9b65102b/touchpad.yml)
- `libinput debug-events --verbose` output: [libinput_debug-events.txt](/uploads/9f697ca8defc21f161c9c0713c53374a/libinput_debug-events.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/818Compose indicator LED not supported2022-11-18T04:31:43ZJan TojnarCompose indicator LED not supportedComing from https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/204#note_460261, I would like to get a LED indicator that <kbd>Compose</kbd> mode is active working, if possible. The Kana and Compose indicators are s...Coming from https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/204#note_460261, I would like to get a LED indicator that <kbd>Compose</kbd> mode is active working, if possible. The Kana and Compose indicators are supposedly supported by [keyboards running QMK](https://docs.qmk.fm/#/feature_led_indicators?id=configuration-options), among others.
Now, I tried running `hid-recorder` but it really only showed the key press and release of <kbd>Caps Lock</kbd> (since I am setting `setxkbmap -option compose:caps`). When I disabled the <kbd>Compose</kbd> with `setxkbmap -option` the `hid-recorder` output did not change (except for timestamps). I saw some `SET_REPORT` USB HID packets in Wireshark (also when pressing Scroll Lock after enabling it with `xmodmap -e "add mod3 = Scroll_Lock"`), which I presume actually control the LED status.
According to _HID Usage Tables FOR Universal Serial Bus (USB), Version 1.3_, the AT-101 code for Compose is 127. That matches [what libinput has](https://gitlab.freedesktop.org/libinput/libinput/blob/10124797b502f3dd308919b7bab80752483d0f6b/include/linux/linux/input-event-codes.h#L204) but apparently, the key is officially named “Keyboard Left GUI” and doubles as Windows key. When I use its Usage ID as per HID [`0xE3` in QMK](https://github.com/qmk/qmk_firmware/blob/bd044ae5fff8b811caaf542f0d31d73f3c50ec36/quantum/keycode.h#L463), `hid-recorder` in fact reports it as a modifier:
```
# LeftControl: 0 | LeftShift: 0 | LeftAlt: 0 | Left GUI: 1 | RightControl: 0 | RightShift: 0 | RightAlt: 0 | Right GUI: 0 | # |Keyboard ['0x70000', '0x70000', '0x70000', '0x70000', '0x70000', '0x70000']
E: 000003.433255 8 08 00 00 00 00 00 00 00
```
And it appears to the system as Super key so I am not really sure creating a key that will be recognized as Compose is possible.
And either way, it will likely require cooperation with input method, as unlike the “Locks”, the Compose mode ends when a typed Compose sequence does (or invalid sequence is entered).
Not even sure if the Compose indicator is worth it, as it would most likely be only useful in TTY – modern desktops already visually indicate it next to cursor.https://gitlab.freedesktop.org/libinput/libinput/-/issues/815Huawei M-Pencil 2 not registered as Stlylus but as touchscreen2022-12-20T06:57:17Zm bruchertHuawei M-Pencil 2 not registered as Stlylus but as touchscreen## Summary
<!--
Summarize the bug encountered concisely. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html for
detailed instructions to report bugs
-->
Stylus touch events seem to be reported as a separate inpu...## Summary
<!--
Summarize the bug encountered concisely. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html for
detailed instructions to report bugs
-->
Stylus touch events seem to be reported as a separate input device with position and pressure data by the kernel, but libinput reports them as part of the touchscreen with pressure data missing.
The expected behaviour would be for them to be reported as stylus events, like with pen tablets.
```
Device: Huawei Matebook E 2022
Stylus: Huawei M-Pencil 2
```
## Steps to reproduce
In xournal++ drawing with the pen and with a finger is the same, without pressure data. In the xournal++ settings, the pen is not registered as a separate device.
<!-- How to reproduce the issue on a developer machine - this is very important -->
## Required information
<!-- Note: if your libinput version is older than the current stable version,
please reproduce with a current version instead -->
- libinput version: `1.21.0`
- hardware information:
```
Operating System: Fedora Linux 37
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 6.1.0-0.rc0.20221011git60bb8154d1d7.8.vanilla.1.fc37.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × 11th Gen Intel® Core™ i3-1110G4 @ 1.80GHz
Memory: 7.6 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics
Manufacturer: HUAWEI
Product Name: DRC-WXX
System Version: M1010
```
- `libinput record` output: [libinput-record.txt](/uploads/1707f4e08c8590e36e6fe024ab4a4993/libinput-record.txt)
- `libinput debug-events --verbose` output: [libinput-debug-events.txt](/uploads/7fbe8dbd25c000670dc165ef0eddd6e2/libinput-debug-events.txt)
<!--
Paste any other relevant logs - please use code blocks (```) to format
console output, logs, and code as it's very hard to read otherwise.)
Do not paste logs longer than 10 lines, **attach** those instead.
If your libinput record is longer than 5-10s, we will not be able to process
it.
-->https://gitlab.freedesktop.org/libinput/libinput/-/issues/810Be more lenient about larger involuntary finger motion during tap2023-06-14T03:19:02ZSesterBe more lenient about larger involuntary finger motion during tap## Summary
On Windows, when tapping the touchpad, the cursor is reset to the initial position if it has been moved just a bit, I ask for this behaviour on Linux KDE as well.
## Feature details
I think behaviour as observed on Windows ...## Summary
On Windows, when tapping the touchpad, the cursor is reset to the initial position if it has been moved just a bit, I ask for this behaviour on Linux KDE as well.
## Feature details
I think behaviour as observed on Windows 10 22H2 would be fine.
If the finger is lifted before the tap-to-click timeout, small movements of the cursor should be reverted.
If the finger stays down long enough, no revert should take place.
Tap-to-click has to be enabled.
## Affected Hardware
Touchpads, chiefly.
## Implementation in Other Systems
On Windows 10 22H2 (dual-boot):
1. The finger touches the touchpad.
2. The finger moves a bit, the cursor moves as well.
3. The finger is lifted within the tap-to-click timeout.
4. The cursor's position is reset to where it was at the beginning of the touch.
5. A click is issued at that initial position.
## Hardware information
$ cat /sys/class/dmi/id/modalias
dmi:bvnAmericanMegatrendsInc.:bvr208:bd04/26/2012:br4.6:svnMedion:pnE6228:pvr1.0:rvnMedion:rnE6228:rvr1.0:cvnMedion:ct10:cvr1.0:sku0:
Model: Medion Akoya E6228, MD99050
~> udevadm info /sys/class/input/event5
P: /devices/platform/i8042/serio2/input/input10/event5
N: input/event5
S: input/by-path/platform-i8042-serio-2-event-mouse
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-2-event-mouse
E: DEVNAME=/dev/input/event5
E: DEVPATH=/devices/platform/i8042/serio2/input/input10/event5
E: ID_BUS=i8042
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=41
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_TOUCHPAD_INTEGRATION=internal
E: ID_INPUT_WIDTH_MM=74
E: ID_PATH=platform-i8042-serio-2
E: ID_PATH_TAG=platform-i8042-serio-2
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=11/2/7:isa0060/serio2
E: LIBINPUT_FUZZ_00=8
E: LIBINPUT_FUZZ_01=8
E: LIBINPUT_FUZZ_35=8
E: LIBINPUT_FUZZ_36=8
E: MAJOR=13
E: MINOR=69
E: SUBSYSTEM=input
E: USEC_INITIALIZED=6746338https://gitlab.freedesktop.org/libinput/libinput/-/issues/783A need for a new and more consistent Mouse Acceleration profile. (Inspired by...2022-07-09T08:55:09ZFeldworA need for a new and more consistent Mouse Acceleration profile. (Inspired by Windows Operating System)<!--
Before your file a feature request, please read
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
The amount of developer time libinput has available is very small.
Requesting a feature is no guarantee tha...<!--
Before your file a feature request, please read
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
The amount of developer time libinput has available is very small.
Requesting a feature is no guarantee that it will get implemented. Someone
(you!) needs to step up to do the work.
-->
## Summary
After some years of `libinput` and `evdev` experience, I have came up with a conclusion that
the [pointer acceleration profiles: `Flat` and `Adaptive`][1] might not be enough for an average user of Linux systems.
Especially if the user is coming from one of the most popular desktop operating systems Windows.
The mouse behaviour might not appear too different, but it definitely have at a very least a subconcious resistance.
So to ease this resistance, I believe and I think that an implementation of a new Mouse Acceleration profile is required.
This Mouse Acceleration profile should be loosely based on Enhance Pointer Precision feature found in Windows Mouse Properties.
Some people believe this is a personal preference , but it's no longer a personal preference,
once it affects millions of people with millions of pointer devices.
At the very least this would allow the possibility of a more standard behaviour in computer mouses.
[1]: https://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html#pointer-acceleration-profiles
<!-- Summarize the requested feature in a few sentences. -->
## Feature details
The new Mouse Acceleration profile should allow to feel the average Windows Mouse user at home.
**The suggestive name for this new mouse acceleration profile:** `ballistic`
<!-- A step-by-step list of what the feature should achieve (where applicable) -->
## Affected Hardware
Mouse pointer devices, of the Windows operating system users.
<!-- Which hardware types would be affected by this -->
## Implementation in Other Systems
### Windows Operating System
Enhance Pointer Precision feature found in Windows Mouse Properties.
I'm not sure how much of a help this might be, but I've found:
[An archived resource about Mouse Acceleration in Windows.](https://web.archive.org/web/20101222190833/http://www.microsoft.com/whdc/archive/pointer-bal.mspx) ([Mirror](https://superuser.com/a/1706565/740880)) [(Discussion)](https://news.ycombinator.com/item?id=23269286)
![image](/uploads/cb108c0ac24ff3fa880eec81d8e8aaa1/image.png)
<!-- Does this feature already exist elsewhere? How does it work there? Try
to provide as many details as possible -->https://gitlab.freedesktop.org/libinput/libinput/-/issues/779RFE: libinput analyze-device2022-06-03T11:06:48ZPeter HuttererRFE: libinput analyze-deviceI'm thinking about a helper tool that could be quite useful, specifically for self-debugging. Something that prints basically this information:
```
$ libinput analyze-device /dev/input/event2
libinput version: 1.20
## udev
✅ ID_INPUT pr...I'm thinking about a helper tool that could be quite useful, specifically for self-debugging. Something that prints basically this information:
```
$ libinput analyze-device /dev/input/event2
libinput version: 1.20
## udev
✅ ID_INPUT property is set
✅ ID_INPUT_TOUCHPAD property is set
✗ ID_INPUT_MOUSE property is set
✗ ID_INPUT_POINTINGSTICK property is set
## evdev
✓ device is is a clickpad
⚠️ device is a semi-mt touchpad
```
The output ideally in nicely formatted columns, and with coloured output.
The goal here would be to identify common issues quickly instead of having to dig through various other output files. This could also then be folded into the documentation for some self-help.
The colouring of the output is the tricky bit because ideally anything red should indicate an actual issue. But just a yes/no doesn't mean something is a bug:
- ID_INPUT is an obvious yes/no, we need that property, always
- ID_INPUT_TOUCHPAD *may* be set, but must not be set if e.g. ID_INPUT_MOUSE is set. Or it must be set no other ID_INPUT is set.
- ID_INPUT_POINTINGSTICK and ID_INPUT_TABLET_PAD must only be set if ID_INPUT_MOUSE or ID_INPUT_TABLET are set, respectively.
- "is a clickpad" is just either/or. This would also apply to touchpad/keyboard integration
- semi-mt is just a warning, it'ss not a problem per se but it negatively affects libinput's behaviour
- etc.
Writing this in python would be trivial enough (the technical parts anyway) but if we want to integrate from libinput it gets a bit more complicated, so it may actually be easier to write this in C.https://gitlab.freedesktop.org/libinput/libinput/-/issues/748Libinput in asynchronous compositor2022-09-07T23:02:29ZJulian OrthLibinput in asynchronous compositorI'm writing an asynchronous Wayland compositor. By this I mean that there are no blocking operations. (Some components such as the graphics drivers might perform blocking operations but this is out of my control.) In particular there is ...I'm writing an asynchronous Wayland compositor. By this I mean that there are no blocking operations. (Some components such as the graphics drivers might perform blocking operations but this is out of my control.) In particular there is no way for me to call out to logind to acquire a device file descriptor without returning to the main loop.
At this point I have written an embedded X backend and I am now trying to write a native backend using libinput. Based on the libinput documentation my first intention was to use a udev context that discovers devices on its own. However, this requires me to call out to logind in the callbacks which is not possible as described above.
Instead, my intention now is to use udev manually to discover devices. Once udev reports a device I call out to logind to take the device. When logind returns successfully, I use a libinput path context to add the device. In the callback I would then look up the file descriptor in my list of opened devices.
I have not yet implemented this but it seems that it should work.
On the other hand, it might be better to enhance the libinput api to better support asynchronous application. For example, instead of using callbacks, libinput could inform the application of devices that need to be opened by providing a new event type. The application could then open the device at its own pace and later call back into libinput with the already opened file descriptor.
Are you aware of other users of libinput that have encountered and solved this problem? Do you think my solution using a path context is workable and future proof? What do you think about my suggested api enhancement?https://gitlab.freedesktop.org/libinput/libinput/-/issues/736Support 3d connexion space mouse2022-02-14T08:25:22ZAlberto FanjulSupport 3d connexion space mouse![image](/uploads/a09a80816d466c832d1c6cefdd828b9b/image.png)
I'm testing this device and is working as expected, but userspace drivers are using x11 events.
https://github.com/FreeSpacenav/spacenavd/issues/58
I test the usb device it...![image](/uploads/a09a80816d466c832d1c6cefdd828b9b/image.png)
I'm testing this device and is working as expected, but userspace drivers are using x11 events.
https://github.com/FreeSpacenav/spacenavd/issues/58
I test the usb device itself and report is really simple (two buttons and 6 axis):
```
$ sudo usbhid-dump -a1:13 -i0 | grep -v : | xxd -r -p | hidrd-convert -o spec
Usage Page (Desktop), ; Generic desktop controls (01h)
Usage (Multi Axis Ctrl), ; Multi-axis controller (08h, application collection)
Collection (Application),
Collection (Physical),
Report ID (1),
Logical Minimum (-350),
Logical Maximum (350),
Physical Minimum (-1400),
Physical Maximum (1400),
Unit Exponent (12),
Unit (Centimeter),
Usage (X), ; X (30h, dynamic value)
Usage (Y), ; Y (31h, dynamic value)
Usage (Z), ; Z (32h, dynamic value)
Report Size (16),
Report Count (3),
Input (Variable, Relative),
End Collection,
Collection (Physical),
Report ID (2),
Usage (Rx), ; Rx (33h, dynamic value)
Usage (Ry), ; Ry (34h, dynamic value)
Usage (Rz), ; Rz (35h, dynamic value)
Report Size (16),
Report Count (3),
Input (Variable, Relative),
End Collection,
Collection (Logical),
Report ID (3),
Usage Page (Desktop), ; Generic desktop controls (01h)
Usage Page (Button), ; Button (09h)
Usage Minimum (01h),
Usage Maximum (02h),
Logical Minimum (0),
Logical Maximum (1),
Physical Minimum (0),
Physical Maximum (1),
Report Size (1),
Report Count (2),
Input (Variable),
Report Count (14),
Input (Constant, Variable),
End Collection,
Collection (Logical),
Report ID (4),
Usage Page (LED), ; LEDs (08h)
Usage (4Bh),
Logical Minimum (0),
Logical Maximum (1),
Report Count (1),
Report Size (1),
Output (Variable),
Report Count (1),
Report Size (7),
Output (Constant, Variable),
End Collection,
Usage Page (FF00h), ; FF00h, vendor-defined
Usage (01h),
Collection (Logical),
Logical Minimum (-128),
Logical Maximum (127),
Report Size (8),
Usage (3Ah),
Collection (Logical),
Report ID (5),
Usage (20h),
Report Count (1),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (6),
Usage (21h),
Report Count (1),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (7),
Usage (22h),
Report Count (1),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (8),
Usage (23h),
Report Count (7),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (9),
Usage (24h),
Report Count (7),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (10),
Usage (25h),
Report Count (7),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (11),
Usage (26h),
Report Count (1),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (19),
Usage (2Eh),
Report Count (1),
Feature (Variable),
End Collection,
Collection (Logical),
Report ID (25),
Usage (31h),
Report Count (4),
Feature (Variable),
End Collection,
End Collection,
End Collection
```
evtest is too really simple:
```
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0x46d product 0xc626 version 0x111
Input device name: "3Dconnexion SpaceNavigator"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 256 (BTN_0)
Event code 257 (BTN_1)
Event type 2 (EV_REL)
Event code 0 (REL_X)
Event code 1 (REL_Y)
Event code 2 (REL_Z)
Event code 3 (REL_RX)
Event code 4 (REL_RY)
Event code 5 (REL_RZ)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Event type 17 (EV_LED)
Event code 8 (LED_MISC) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1644343535.132211, type 2 (EV_REL), code 4 (REL_RY), value 3
Event: time 1644343535.132211, -------------- SYN_REPORT ------------
Event: time 1644343535.148180, type 2 (EV_REL), code 4 (REL_RY), value 10
Event: time 1644343535.148180, -------------- SYN_REPORT ------------
Event: time 1644343535.164186, type 2 (EV_REL), code 4 (REL_RY), value 13
Event: time 1644343535.164186, -------------- SYN_REPORT ------------
Event: time 1644343535.180201, type 2 (EV_REL), code 4 (REL_RY), value 14
Event: time 1644343535.180201, -------------- SYN_REPORT ------------
Event: time 1644343535.196189, type 2 (EV_REL), code 4 (REL_RY), value 18
Event: time 1644343535.196189, -------------- SYN_REPORT ------------
Event: time 1644343535.212294, type 2 (EV_REL), code 4 (REL_RY), value 21
Event: time 1644343535.212294, -------------- SYN_REPORT ------------
Event: time 1644343535.228181, type 2 (EV_REL), code 4 (REL_RY), value 22
Event: time 1644343535.228181, -------------- SYN_REPORT ------------
Event: time 1644343535.236205, type 2 (EV_REL), code 1 (REL_Y), value 1
Event: time 1644343535.236205, -------------- SYN_REPORT ------------
Event: time 1644343535.244166, type 2 (EV_REL), code 4 (REL_RY), value 25
Event: time 1644343535.244166, -------------- SYN_REPORT ------------
Event: time 1644343535.252187, type 2 (EV_REL), code 1 (REL_Y), value 5
Event: time 1644343535.252187, -------------- SYN_REPORT ------------
...
```
How can this device by detect by libinput?https://gitlab.freedesktop.org/libinput/libinput/-/issues/729Support on button scroll for tablets2024-03-11T14:58:54ZLucian HollandSupport on button scroll for tablets## Summary
It's common for users of graphics tablet devices to want to use the tablet as their primary pointing device at least some of the time. Although some dedicated graphics applications (GIMP/Inkscape etc) implement specific table...## Summary
It's common for users of graphics tablet devices to want to use the tablet as their primary pointing device at least some of the time. Although some dedicated graphics applications (GIMP/Inkscape etc) implement specific tablet support, most applications do not, and only respond to generic scroll events. It's therefore very common for tablet users to bind one of the stylus buttons to "on buttons scroll" so that stylus movement can be used to scroll/pan a page. AIUI libinput does not currently recognise on button scroll as an option for most (all?) tablets so there's no way to replicate this directly in libinput. On X11 there are ways around this but on Wayland you're stuck with whatever libinput exposes for your device.
## Feature details
I apologise if I've misunderstood where the problem lies here. I've searched fairly extensively for how to achieve this on Wayland. From reading various bug tickets / StackExchange questions / Reddit threads it seemed like the only way that this could work is if libinput supported it natively, but I'd be very happy to be corrected if there is already some way to achieve this that just needs the desktop environment to expose the appropriate configuration options.
## Affected Hardware
AFAICT, at least most simple tablets without other scrolling support - e.g. Wacom ONE.
## Implementation in Other Systems
Under X11 it's possible to do various things like e.g.
```
/etc/X11/xorg.conf.d/00-mouse.conf
Section "InputClass"
Identifier "system-mouse"
MatchIsPointer "on"
Option "ScrollMethod" "button"
Option "ScrollButton" "3"
EndSection
```
or using `xswetwacom` if libinput is not involved.https://gitlab.freedesktop.org/libinput/libinput/-/issues/707Touchpad with flat profile cannot be set fast enough2022-06-03T04:16:20ZJames ChancellorTouchpad with flat profile cannot be set fast enough## Summary
I have Ubuntu 21.10 running an Xorg session on a laptop with an Elantech touchpad. I would like to have a "flat" acceleration profile with enough speed, but the range of allowable values for "Accel Speed" does not allow this....## Summary
I have Ubuntu 21.10 running an Xorg session on a laptop with an Elantech touchpad. I would like to have a "flat" acceleration profile with enough speed, but the range of allowable values for "Accel Speed" does not allow this.
## Steps to reproduce
First of all, enable the "flat" profile for the touchpad with xinput (this is not exposed via any Ubuntu/Gnome UI):
```
xinput set-prop 'ETPS/2 Elantech Touchpad' 'libinput Accel Profile Enabled' 0, 1
```
I don't really understand what 0, 1 means, but I assume it is something like normalprofile=0 flatprofile=1. The default was `1, 0`. But it works, and the touchpad behaves as I expect -- with the cursor distance proportional to finger distance.
Then set the speed to maximum:
```
xinput set-prop 'ETPS/2 Elantech Touchpad' 'libinput Accel Speed' 1.0
```
For this value, a finger swipe across 100% of the touchpad makes the cursor move about 60% of the way across the screen. This is what seems far too slow for me.
Incidentally, if I try to set this to eg 1.1, I get an error. If I set it to -1.0, the cursor moves only a few pixels in total for a finger swipe across 100% of the touchpad.
## Notes
I realize that preferred touchpad settings are subjective. However I feel that my own preferences here are fairly normal, and either that there's something wrong with my hardware/configuration that is making this very slow, or that if it's intentional then this speed would be too slow for a significant proportion of users.
I believe the ability to use a flat profile for touchpads was added after this issue: https://gitlab.freedesktop.org/libinput/libinput/-/issues/283.
(I have virtually no understanding of how xinput/libinput/Wayland/X all work together or not in case this report is nonsensical.)
## Required information
<!-- Note: if your libinput version is older than the current stable version,
please reproduce with a current version instead -->
- libinput version: 1.18.1
- hardware information: Lenovo Ideapad 510S-14ISK
[libinput-debug-events.out](/uploads/c4534bf91977ea3f412010f432bf7ef9/libinput-debug-events.out)
[libinput-record.out](/uploads/436e78b8539ea53df19f261532816f89/libinput-record.out)
[modalias.out](/uploads/278625bbd349bb73cc352634c85330f9/modalias.out)
[touchpad-edge-detector.out](/uploads/a7eccc2ac2fe885832df89c81b7af3b2/touchpad-edge-detector.out)
[udevadm.out](/uploads/82ed0911723057c15f2a16734e7dce8b/udevadm.out)
[xinput-list-props.out](/uploads/34dda0cbf6cf351813fef477708e85a9/xinput-list-props.out)https://gitlab.freedesktop.org/libinput/libinput/-/issues/698Touchscreen evdev events with timestamp update only are filtered-out2021-12-21T04:52:51ZRémi BernonTouchscreen evdev events with timestamp update only are filtered-out## Summary
As discussed privately with @whot, Wine would benefit from having every evdev event passed through as a libinput event, even if only the EV_MSC / MSC_TIMESTAMP is updated.
## Feature details
To illustrate, this is an extrac...## Summary
As discussed privately with @whot, Wine would benefit from having every evdev event passed through as a libinput event, even if only the EV_MSC / MSC_TIMESTAMP is updated.
## Feature details
To illustrate, this is an extract of a libinput recording (from an unknown generic touchscreen model):
```
- evdev:
- [ 0, 843749, 3, 53, 513] # EV_ABS / ABS_MT_POSITION_X 513 (+1)
- [ 0, 843749, 3, 54, 446] # EV_ABS / ABS_MT_POSITION_Y 446 (-1)
- [ 0, 843749, 3, 60, 513] # EV_ABS / ABS_MT_TOOL_X 513 (+1)
- [ 0, 843749, 3, 61, 446] # EV_ABS / ABS_MT_TOOL_Y 446 (-1)
- [ 0, 843749, 3, 0, 513] # EV_ABS / ABS_X 513 (+1)
- [ 0, 843749, 3, 1, 446] # EV_ABS / ABS_Y 446 (-1)
- [ 0, 843749, 4, 5, 690000] # EV_MSC / MSC_TIMESTAMP 690000
- [ 0, 843749, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +12ms
libinput:
- {time: 0.843749, type: TOUCH_MOTION, slot: 0, seat_slot: 0, point: [171.00, 49.56], transformed: [ 64.04, 34.82]}
- {time: 0.843749, type: TOUCH_FRAME}
- evdev:
- [ 0, 855911, 4, 5, 700000] # EV_MSC / MSC_TIMESTAMP 700000
- [ 0, 855911, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +12ms
- evdev:
- [ 0, 868149, 4, 5, 710000] # EV_MSC / MSC_TIMESTAMP 710000
- [ 0, 868149, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +13ms
- evdev:
- [ 0, 880423, 4, 5, 720000] # EV_MSC / MSC_TIMESTAMP 720000
- [ 0, 880423, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +12ms
```
On Windows, touchscreens generate WM_POINTERUPDATE messages regularly, as long as the touchscreen is touched, or as I believe it, whenever the HID device sends an input report, even if the positions or pointer state did not change.
On Linux, evdev does the same thing, probably because it simply translates HID input reports, but libinput filters out events where only the timestamp is updated. There too, evdev does so only while the touchscreen is touched.
Some Windows applications, and more specifically Unity games somehow expect this behavior for their touchscreen support, and properly implementing it in Wine will be much easier with the evdev events passed through.
## Affected Hardware
Generic touchscreens? I don't know the exact model but it was consistent between a laptop where I checked Windows behavior, and a handheld device where I checked evdev / libinput.
## Implementation in Other Systems
I think it should be straightforward and portable to pass through any update coming from the backend.https://gitlab.freedesktop.org/libinput/libinput/-/issues/640Touch jumps detected when moving single finger fast2021-07-27T05:30:34ZMateusz JończykTouch jumps detected when moving single finger fast## Summary
I can trigger
(EE) event5 - ETPS/2 Elantech Touchpad: kernel bug: Touch jump detected and discarded.
messages in Xorg.log file by striking the touchpad with one finger, very gently and fast.
## Steps to reproduce
Str...## Summary
I can trigger
(EE) event5 - ETPS/2 Elantech Touchpad: kernel bug: Touch jump detected and discarded.
messages in Xorg.log file by striking the touchpad with one finger, very gently and fast.
## Steps to reproduce
Strike the touchpad with one finger, very gently and fast. This sometimes generates this debugging message in Xorg.log.
## Required information
- libinput version: 1.18.0 (compiled from git tag)
- hardware information: HP laptop 17-by0001nw, Elantech touchpad
- `libinput record` output: [record.yml.2021-07-19-21_39_24](/uploads/adeb29c651468179e938803df762a1fb/record.yml.2021-07-19-21_39_24)
- `libinput debug-events --verbose` output:
[libinput-debug-events.html](/uploads/d83119e1408b4e408063a0588d7e071f/libinput-debug-events.html)
<details><summary>Detailed system information</summary>
Hardware: HP laptop 17-by0001nw, Elantech touchpad:
lip 18 18:44:26 mateusz-ubuntu kernel: psmouse serio1: elantech: assuming hardware version 4 (with firmware version 0x5d4f01)
lip 18 18:44:26 mateusz-ubuntu kernel: psmouse serio1: elantech: Synaptics capabilities query result 0x71, 0x1a, 0x0b.
lip 18 18:44:26 mateusz-ubuntu kernel: psmouse serio1: elantech: Elan sample query result 02, b7, 97
lip 18 18:44:26 mateusz-ubuntu kernel: input: ETPS/2 Elantech Touchpad as /devices/platform/i8042/serio1/input/input5
Software: Ubuntu 20.04, libinput 1.18.0 (compiled from git), Linux 5.13.2 (compiled from source, with one patch to print decoded Elantech touchpad traffic)
udevadm info /sys/class/input/event5:
P: /devices/platform/i8042/serio1/input/input5/event5
N: input/event5
L: 0
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVPATH=/devices/platform/i8042/serio1/input/input5/event5
E: DEVNAME=/dev/input/event5
E: MAJOR=13
E: MINOR=69
E: SUBSYSTEM=input
E: USEC_INITIALIZED=30513597
E: ID_INPUT=1
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_WIDTH_MM=114
E: ID_INPUT_HEIGHT_MM=48
E: ID_BUS=i8042
E: ID_SERIAL=noserial
E: ID_PATH=platform-i8042-serio-1
E: ID_PATH_TAG=platform-i8042-serio-1
E: ID_INPUT_TOUCHPAD_INTEGRATION=internal
E: LIBINPUT_DEVICE_GROUP=11/2/e:isa0060/serio1
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
cat /sys/class/dmi/id/modalias
dmi:bvnInsyde:bvrF.63:bd03/25/2021:br15.63:efr74.36:svnHP:pnHPLaptop17-by0xxx:pvrType1ProductConfigId:sku4UF12EA#AKD:rvnHP:rn84CA:rvrKBCVersion74.36:cvnHP:ct10:cvrChassisVersion:
touchpad-edge-detector - OK:
Touchpad ETPS/2 Elantech Touchpad on /dev/input/by-path/platform-i8042-serio-1-event-mouse
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..3553], y [0..1499]
Touchpad sends: x [6..3553], y [61..1499] |^C|
Touchpad size as listed by the kernel: 114x48mm
User-specified touchpad size: 115x51mm
Calculated ranges: 3547/1438
Suggested udev rule:
[...]
</details>
----
Hello,
As asked in https://wayland.freedesktop.org/libinput/doc/latest/touchpad-jumping-cursors.html , I'm reporting this phenomenon as a bug. Since some time, I was seeing the "Touch jump detected and discarded" messages in Xorg.log. For a long time I did not know when they happen. Finally, I have discovered that they happen as described here.https://gitlab.freedesktop.org/libinput/libinput/-/issues/621GTK 4 support for debug GUI2021-08-05T19:30:12ZIssam E. MaghniGTK 4 support for debug GUIHi,
is it possible to add GTK 4 for debug UI? For now, only GTK+ 3 is supported.
This would reduce dependencies on newer systems.
Thank you.Hi,
is it possible to add GTK 4 for debug UI? For now, only GTK+ 3 is supported.
This would reduce dependencies on newer systems.
Thank you.https://gitlab.freedesktop.org/libinput/libinput/-/issues/616Button debouncing does not work with my "E-Signal USB Gaming Mouse" (ZeleSouris)2022-05-20T23:58:17ZMaxime ChéramyButton debouncing does not work with my "E-Signal USB Gaming Mouse" (ZeleSouris)## Summary
Accidental double clicks are not filtered out by libinput of a defective mouse .
Here are the debug events for a *simple click":
```
event23 - debounce state: DEBOUNCE_STATE_IS_UP → DEBOUNCE_EVENT_PRESS → DEBOUNCE_STATE_IS_...## Summary
Accidental double clicks are not filtered out by libinput of a defective mouse .
Here are the debug events for a *simple click":
```
event23 - debounce state: DEBOUNCE_STATE_IS_UP → DEBOUNCE_EVENT_PRESS → DEBOUNCE_STATE_IS_DOWN_WAITING
-event23 POINTER_BUTTON +9.380s BTN_LEFT (272) pressed, seat count: 1
event23 - debounce state: DEBOUNCE_STATE_IS_DOWN_WAITING → DEBOUNCE_EVENT_RELEASE → DEBOUNCE_STATE_IS_UP_DELAYING
event23 - debounce state: DEBOUNCE_STATE_IS_UP_DELAYING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_UP
event23 POINTER_BUTTON +9.400s BTN_LEFT (272) released, seat count: 0
event23 - debounce state: DEBOUNCE_STATE_IS_UP → DEBOUNCE_EVENT_PRESS → DEBOUNCE_STATE_IS_DOWN_WAITING
event23 POINTER_BUTTON +9.422s BTN_LEFT (272) pressed, seat count: 1
event23 - debounce state: DEBOUNCE_STATE_IS_DOWN_WAITING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_DOWN
event23 - debounce state: DEBOUNCE_STATE_IS_DOWN → DEBOUNCE_EVENT_RELEASE → DEBOUNCE_STATE_IS_UP_DETECTING_SPURIOUS
event23 POINTER_BUTTON +9.474s BTN_LEFT (272) released, seat count: 0
event23 - debounce state: DEBOUNCE_STATE_IS_UP_DETECTING_SPURIOUS → DEBOUNCE_EVENT_TIMEOUT_SHORT → DEBOUNCE_STATE_IS_UP_WAITING
event23 - debounce state: DEBOUNCE_STATE_IS_UP_WAITING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_UP
```
and here another click:
```
event23 - debounce state: DEBOUNCE_STATE_IS_UP → DEBOUNCE_EVENT_PRESS → DEBOUNCE_STATE_IS_DOWN_WAITING
-event23 POINTER_BUTTON +78.562s BTN_LEFT (272) pressed, seat count: 1
event23 - debounce state: DEBOUNCE_STATE_IS_DOWN_WAITING → DEBOUNCE_EVENT_RELEASE → DEBOUNCE_STATE_IS_UP_DELAYING
event23 - debounce state: DEBOUNCE_STATE_IS_UP_DELAYING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_UP
event23 POINTER_BUTTON +78.584s BTN_LEFT (272) released, seat count: 0
event23 - debounce state: DEBOUNCE_STATE_IS_UP → DEBOUNCE_EVENT_PRESS → DEBOUNCE_STATE_IS_DOWN_WAITING
event23 POINTER_BUTTON +78.605s BTN_LEFT (272) pressed, seat count: 1
event23 - debounce state: DEBOUNCE_STATE_IS_DOWN_WAITING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_DOWN
event23 - debounce state: DEBOUNCE_STATE_IS_DOWN → DEBOUNCE_EVENT_RELEASE → DEBOUNCE_STATE_IS_UP_DETECTING_SPURIOUS
event23 POINTER_BUTTON +78.710s BTN_LEFT (272) released, seat count: 0
event23 - debounce state: DEBOUNCE_STATE_IS_UP_DETECTING_SPURIOUS → DEBOUNCE_EVENT_TIMEOUT_SHORT → DEBOUNCE_STATE_IS_UP_WAITING
event23 - debounce state: DEBOUNCE_STATE_IS_UP_WAITING → DEBOUNCE_EVENT_TIMEOUT → DEBOUNCE_STATE_IS_UP
```
## Steps to reproduce
Normal clicks, 10% of the time maybe.
## Required information
<!-- Note: if your libinput version is older than the current stable version,
please reproduce with a current version instead -->
- libinput version: 1.16.4-3
- hardware information: E-Signal USB Gaming Mouse
- `libinput record` output: [record.yml](/uploads/cb7b970543c4846b84964a5bfbfcb705/record.yml)https://gitlab.freedesktop.org/libinput/libinput/-/issues/591Touchpad cursor speed it too low with flat acceleration profile2022-06-03T04:16:19ZJakub NowakTouchpad cursor speed it too low with flat acceleration profile## Summary
<!--
Summarize the bug encountered concisely. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html for
detailed instructions to report bugs
-->
The cursor speed is too low with flat acceleration profil...## Summary
<!--
Summarize the bug encountered concisely. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html for
detailed instructions to report bugs
-->
The cursor speed is too low with flat acceleration profile and acceleration speed set to maximum. I would like the cursor to be about twice as fast.
## Steps to reproduce
I've set acceleration profile to flat and acceleration speed to maximum (i.e. 1.000000).
## Required information
<!-- Note: if your libinput version is older than the current stable version,
please reproduce with a current version instead -->
- libinput version: 1.17.0
- `libinput record`: [libinput.record](/uploads/e32c24402c29b82908ec41fa6f86dd21/libinput.record)
- `libinput debug-events --verbose`: [libinput.debug-events](/uploads/f8de813fbc49f21c0be154f82bbbd379/libinput.debug-events)
- `xinput list-props`: [xinput.list-props](/uploads/aa3f2df3a9da7be15ba279f79cff54f6/xinput.list-props)
- `udevadm info`: [udevadm.info](/uploads/24e5b4b88d9da546c1314df5e0357479/udevadm.info)
- `/sys/class/dmi/id/modalias`:
```
dmi:bvnDellInc.:bvrA02:bd09/03/2013:br4.6:svnDellInc.:pnLatitudeE6440:pvr01:rvnDellInc.:rn0YX2X3:rvrA00:cvnDellInc.:ct9:cvr:
```
- laptop model: DELL Latitude E6440
<!--
Paste any other relevant logs - please use code blocks (```) to format
console output, logs, and code as it's very hard to read otherwise.)
Do not paste logs longer than 10 lines, **attach** those instead.
If your libinput record is longer than 5-10s, we will not be able to process
it.
-->https://gitlab.freedesktop.org/libinput/libinput/-/issues/583Disable mouse scroll wheel while middle click is held2021-03-17T03:44:21ZJosé ExpósitoDisable mouse scroll wheel while middle click is held<!--
Before your file a feature request, please read
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
The amount of developer time libinput has available is very small.
Requesting a feature is no guarantee tha...<!--
Before your file a feature request, please read
https://wayland.freedesktop.org/libinput/doc/latest/what-is-libinput.html
The amount of developer time libinput has available is very small.
Requesting a feature is no guarantee that it will get implemented. Someone
(you!) needs to step up to do the work.
-->
## Summary
<!-- Summarize the requested feature in a few sentences. -->
Do not send axis/scroll events when the mouse wheel is clicked.
## Feature details
<!-- A step-by-step list of what the feature should achieve (where applicable) -->
This feature was already requested in https://gitlab.freedesktop.org/libinput/libinput/-/issues/19 including details.
My personal use case is that I have a (cheap) mouse whose scroll wheel doesn't work that well and some times it scrolls when I press it. Trying to open a browser link in a new tab can be frustrating because the page scrolls on click.
I can submit a merge request including [the required changes](https://gitlab.freedesktop.org/libinput/libinput/-/issues/19#note_830466) to implement this feature.
## Affected Hardware
<!-- Which hardware types would be affected by this -->
Mice with a clickable scroll wheel.
## Implementation in Other Systems
<!-- Does this feature already exist elsewhere? How does it work there? Try
to provide as many details as possible -->
This is the default behavior in Windows 10 (Chrome).https://gitlab.freedesktop.org/libinput/libinput/-/issues/567“Mouse mode” support2021-03-29T13:44:49ZBastien Nocera“Mouse mode” supportSome devices, like infra-red remotes, have “mouse mode” toggle buttons. Given the relative simplicity of the remote control subsystem, it would be useful if libinput could handle this mode toggle, and generate mouse movement events, and ...Some devices, like infra-red remotes, have “mouse mode” toggle buttons. Given the relative simplicity of the remote control subsystem, it would be useful if libinput could handle this mode toggle, and generate mouse movement events, and button clicks.
I could imagine that we'd need:
- a new mouse mode toggle keycode
- libinput to catch this keycode
- mouse movement to be emulated with `KEY_RIGHT`, `KEY_UP`, etc.
- assignment for which buttons are left/right buttons
I think that the "rc" subsystem should probably have a way to attach information about that last item to the remote's keymap, otherwise I'm not too sure how convenient it would be to have remote-specific info in multiple places.
Original bug report on linux-media:
https://www.spinics.net/lists/linux-media/msg186050.htmlhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/566Thumb rejection interferes with pinch gestures2021-05-19T08:02:58ZnovenaryThumb rejection interferes with pinch gestures## Summary
It's way too difficult to initiate a pinch gesture with the index and thumb on my laptop. Other finger combinations (both thumbs or no thumbs) work fine.
## Steps to reproduce
- Open an application which handles pinch gestu...## Summary
It's way too difficult to initiate a pinch gesture with the index and thumb on my laptop. Other finger combinations (both thumbs or no thumbs) work fine.
## Steps to reproduce
- Open an application which handles pinch gestures (recent Firefox Nightly with `apz.gtk.touchpad_pinch.enabled`, GNOME Image Viewer, gtk3-demo)
- Attempt a pinch gesture with index and thumb => sometimes the cursor moves, sometimes I get scrolling instead (#550), sometimes I get zooming as expected, I can't really tell whether it depends on timing or how my thumb touches the surface
- Attempt a pinch gesture with another pair of fingers => works as intended
The following hack to disable thumb rejection does help with the cursor moving problem. Swipe gestures (scrolling) are very easy to perform in comparsion, they feel very natural.
```diff
--- a/src/evdev-mt-touchpad-thumb.c
+++ b/src/evdev-mt-touchpad-thumb.c
@@ -392,6 +392,7 @@
struct quirks *q;
tp->thumb.detect_thumbs = false;
+ return;
if (!tp->buttons.is_clickpad)
return;
```
## Required information
- libinput version: 1.16.4
- hardware information: Lenovo Ideapad 320S-14IKB
- `libinput record` output: attached a log of me trying to pinch three times, but only got cursor moves [record.log](/uploads/72b61bdcc70618fdcdc450bedb2f29a7/record.log)
- `libinput debug-events --verbose` output: the final part of the log is a failed attempt to pinch [events.log](/uploads/301c2b68716d540072659ee888298ca1/events.log)Matt MayfieldMatt Mayfield