libinput issueshttps://gitlab.freedesktop.org/libinput/libinput/-/issues2024-03-17T18:59:48Zhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/298Request for three fingers click+movement2024-03-17T18:59:48ZPedro SantosRequest for three fingers click+movement## Summary
Request for a movement of three fingers touch the touchpad to cause the movement of the pointer
Request for a mouse left button down + up while moving the pointer with three fingers
## Feature details
1. rest three fingers ...## Summary
Request for a movement of three fingers touch the touchpad to cause the movement of the pointer
Request for a mouse left button down + up while moving the pointer with three fingers
## Feature details
1. rest three fingers at the touchpad
1. move the three fingers at the same time for the same direction
1. the pointer follows the the movement made by the three fingers
1. move the pointer to the window title bar
2. touch the touchpad with three fingers
2. move the three fingers to the right
2. the window moves to the right, as if the mouse left button were pressed
2. remove two fingers from the touchpad
2. the window stops moving as if the mouse left button stoped being pressed
2. keep moving the remaining finger on the touchpad
2. the pointer keeps moving following the remaining finger
## Implementation in Other Systems
This was the default behaviour in Apple trackpads in 2012 macbooks. Recently this behaviour for three fingers touch/movement is an options in the trackpad preferences.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/286hysteresis enabled by wobble detection unnecessarily2024-01-29T14:26:17ZTomáš Janoušekhysteresis enabled by wobble detection unnecessarily## Summary
During normal laptop use, hysteresis is always sooner or later (minutes rather than days) turned on by wobble detection and since then, the touchpad is imprecise (as described in <https://bugs.freedesktop.org/show_bug.cgi?i...## Summary
During normal laptop use, hysteresis is always sooner or later (minutes rather than days) turned on by wobble detection and since then, the touchpad is imprecise (as described in <https://bugs.freedesktop.org/show_bug.cgi?id=98839>).
## Steps to reproduce
1. `$ sudo ./libinput-debug-events --verbose /dev/input/event1`
2. move finger vertically
3. sooner or later, `event1 - hysteresis enabled.` appears
The output around this happening looks like this:
```
event1 POINTER_MOTION +16.90s -0.23/ 0.92 ( -1.00/ +3.91)
event1 POINTER_MOTION +16.91s 0.00/ 1.22 ( +0.00/ +5.22)
event1 POINTER_MOTION +16.92s 0.23/ 1.53 ( +1.00/ +6.52)
event1 POINTER_MOTION +16.93s -0.23/ 1.53 ( -1.00/ +6.52)
event1 POINTER_MOTION +16.95s 0.23/ 1.53 ( +1.00/ +6.52)
event1 - hysteresis enabled. See https://wayland.freedesktop.org/libinput/doc/latest/touchpad-jitter.html for details
event1 POINTER_MOTION +16.97s -2.81/ 2.29 (-12.00/ +9.78)
event1 POINTER_MOTION +16.98s 0.70/ 0.76 ( +3.00/ +3.26)
event1 POINTER_MOTION +16.99s 0.70/ 1.53 ( +3.00/ +6.52)
event1 POINTER_MOTION +17.01s 0.47/ 1.37 ( +2.00/ +5.87)
```
Note that this touchpad has absolutely no jitter when holding a finger still even before hysteresis is turned on -- I can confirm this by running `libinput-debug-events`. There's not a single movement between two `button state:` events if I hold the finger still. There is also no fuzz in the kernel:
```
$ sudo ./libinput-measure-fuzz
Using SynPS/2 Synaptics TouchPad: /dev/input/event1
Checking udev property... not set
Checking axes... is zero
$ sudo udevadm info -e | grep -i -c fuzz
0
```
I'm convinced this means the hysteresis is done in touchpad firmware and I am very happy with it: I've been running for more than a year with wobble detection commented out and it just works: the touchpad reacts precisely to any little movement and there's no wobble ever.
I also tried playing a bit with the wobble detection, incresing the number of right-left-rights that need to happen for hysteresis to kick in.
```
static const char r_l_r = 0x15; /* {Right, Left, Right, Left, Right} */
t->hysteresis.x_motion_history |= (1 << 4);
```
^^ with this I could enable it by moving the finger vertically in a few seconds.
```
static const char r_l_r = 0x55; /* {Right, Left, Right, Left, Right, Left, Right} */
t->hysteresis.x_motion_history |= (1 << 6);
```
^^ this was harder, but I could still do it within a minute.
I'm sure I'd hit this sooner or later within my X uptime, and since there's no way to turn it off (sans attaching gdb to X), I'd be a very sad man afterwards. Therefore I think the wobble detection needs to be made somewhat smarter, perhaps taking both axes into account. As I don't happen to have any wobbling touchpad around, I'm not sure I can help much further. :-(
Alternatively, I'd be just as happy with adding a quirk or udev rule that tells libinput not to ever enable hysteresis. But I understand that you'd rather have me build my own libinput package than introduce a configuration parameter, and I can accept that — I don't really mind running a patched version of libinput on our laptops but I think this issue hits many other ThinkPads out there. It's probably less pronounced than it used to be in the days of the linked bugzilla thanks to 6936a15558f7baa047bdb7e31604ef29be1ae552 and ea7498ef971350454db9c78b9ba160e7d6bb455b, but I perceive the inability to precisely make one-pixel movements/scrolls a bug.
## libinput version you encountered the bug on
$ git describe --tags
1.13.0-57-gcac9d537
and all other versions of libinput since e8dffbd73a1b3c17716f972f210e420de94028c2 was merged.
## Hardware information:
ThinkPad T25
```
dmi:bvnLENOVO:bvrN1QET79W(1.54):bd11/16/2018:svnLENOVO:pn20K70000GE:pvrThinkPad25:rvnLENOVO:rn20K70000GE:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
```
```
P: /devices/platform/i8042/serio1/input/input2/event1
N: input/event1
L: 0
S: input/by-path/platform-i8042-serio-1-event-mouse
E: DEVPATH=/devices/platform/i8042/serio1/input/input2/event1
E: SUBSYSTEM=input
E: DEVNAME=/dev/input/event1
E: MAJOR=13
E: MINOR=65
E: USEC_INITIALIZED=18924531
E: ID_INPUT=1
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_WIDTH_MM=98
E: ID_INPUT_HEIGHT_MM=53
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/7:isa0060/serio1
E: DEVLINKS=/dev/input/by-path/platform-i8042-serio-1-event-mouse
```
We have the exact same problem on my wife's ThinkPad T440p but as mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=98839#c71, the touchpad firmware that came with the laptop did wobble for a second until its hysteresis kicked in and we had to update the firmware. Since then, she's running libinput with commented out wobble-detection and it works brilliantly.
## Other log output:
- `libinput record` output: [libinput-record.txt](/uploads/e5acd82bf78957b3e00072a0a6132c1f/libinput-record.txt)
- `libinput debug-events --verbose` output: [libinput-debug-events.txt](/uploads/8d1ee34e7f0c32299758880affb1cfa3/libinput-debug-events.txt)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/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/536Continue to slowly move the cursor when reaching the edge of the touchpad2023-04-12T01:27:44ZJoseph AveltsevContinue to slowly move the cursor when reaching the edge of the touchpad## Feature details
When you make a selection (e. g. text, selection rectangle, or something) and reach the edge of a touchpad the cursor stops moving. I'd like it to slowly continue to move as it's done on Windows.
## Implementation in...## Feature details
When you make a selection (e. g. text, selection rectangle, or something) and reach the edge of a touchpad the cursor stops moving. I'd like it to slowly continue to move as it's done on Windows.
## Implementation in Other Systems
It exists on Windows.https://gitlab.freedesktop.org/libinput/libinput/-/issues/7RFE: Proposal for libinput mouse wheel acceleration2023-03-08T13:06:18ZBugzilla Migration UserRFE: Proposal for libinput mouse wheel acceleration## Submitted by Adam Goode
Assigned to **Wayland bug list**
**[Link to original bug (#101141)](https://bugs.freedesktop.org/show_bug.cgi?id=101141)**
## Description
Let me start with this proposal for mouse wheel acceleration in l...## Submitted by Adam Goode
Assigned to **Wayland bug list**
**[Link to original bug (#101141)](https://bugs.freedesktop.org/show_bug.cgi?id=101141)**
## Description
Let me start with this proposal for mouse wheel acceleration in libinput.
Use case:
- Scrolling through a long document is slow with a mouse wheel
Prior work showing benefits of wheel acceleration:
- macOS
- Chrome OS
Requirements:
- Don't break anything
- Require minimum changes from clients
Proposal:
- Mouse wheel acceleration at the libinput level, only for mouse wheels
- Do no acceleration on values returned from libinput_event_pointer_get_axis_value_discrete, this keeps the promise in the API of reporting "physical mouse wheel clicks" and keeps us from needing to implement a new "get unaccelerated" API
- Ensure that legacy X wheel events (pre-XI2.1) are not accelerated
Open questions:
- Does this cover enough clients without breaking things? Chrome and Firefox support XI2.1, so this would accelerate those programs.
- Under X or XWayland, is it possible to accelerate XI2.1 events but not the legacy events? Or are the legacy events generated automatically?
- Or is it ok to accelerate legacy X wheel events? emacs has scroll acceleration already, and other clients may as well.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/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/329Debounce is not implemented for touchpad physical buttons2022-10-07T16:28:02ZJacob MoroniDebounce is not implemented for touchpad physical buttonsHello,
I'm working with a laptop that has a touchpad with two physical buttons below it, one of which has a tendency to bounce during clicks, resulting in occasional unintended double-clicks.
I see that some debounce code has been adde...Hello,
I'm working with a laptop that has a touchpad with two physical buttons below it, one of which has a tendency to bounce during clicks, resulting in occasional unintended double-clicks.
I see that some debounce code has been added for fallback devices around 1.10, but no such code exists for touchpad devices.
I would have expected the debounce code to apply to any physical button since they're all capable of bouncing.
Thoughts?https://gitlab.freedesktop.org/libinput/libinput/-/issues/235Enable Circular Scrolling2022-07-25T02:39:26Zghost6482Enable Circular ScrollingIt would be great if you add Circular Scrolling feature like in Synaptics driver. Many people have accustomed to it and find this feature useful.It would be great if you add Circular Scrolling feature like in Synaptics driver. Many people have accustomed to it and find this feature useful.https://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/370tablet: configurable eraser button2022-06-10T04:40:06ZPeter Hutterertablet: configurable eraser buttonSome styli have the windows-style eraser button instead of the eraser at the back of the stylus. The button generates proximity events in the device, so the sequence on eraser button press is: stylus proximity out, eraser proximity in, a...Some styli have the windows-style eraser button instead of the eraser at the back of the stylus. The button generates proximity events in the device, so the sequence on eraser button press is: stylus proximity out, eraser proximity in, and the reverse on release.
Users don't always want/need an eraser button but want that button to work normally, so we should make this configurable behaviour.
- [x] we'll need libwacom support for tagging the affected styli
- [ ] any stylus with that functionality needs to export nbuttons + 1 and return the right bits from `has_key()` etc.
- [ ] the eraser button causes a proximity out event of the pen, then in the next evdev frame the proximity in, so we can't detect it as button press directly. We'll have to paper over this correctly.
cc @jigpuhttps://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/168Touchpad jitter on ALPS touchpad2022-04-27T11:47:31ZSimon ButcherTouchpad jitter on ALPS touchpad## Summary
Using the touchpad to move the mouse pointer often (but not 100% of the time) produces exaggerated jitter, making selection of items/tabs very difficult
## Steps to reproduce
Open a few windows such as firefox and start usi...## Summary
Using the touchpad to move the mouse pointer often (but not 100% of the time) produces exaggerated jitter, making selection of items/tabs very difficult
## Steps to reproduce
Open a few windows such as firefox and start using the desktop. The pointer may be stable sometimes, and other times very unstable/jittery. Typically this manifests within the first couple of minutes of use, and 30-50% of mouse movements (especially precision such as text selection or even trying to hold the pointer still) seem affected worse.
## libinput version you encountered the bug on
* Tested on elementary 4.15.0-36-generic libinput 1.10.4-1
* Still occurs after building latest from gitlab repo:
commit 5fd8c7cdb89aff9de61f9aaf75338e5225feaf9e (HEAD -> master, tag: 1.12.2, origin/master, origin/HEAD)
* Also occurs on Ubuntu 18.10 live USB using standard vendor package libinput 1.12.1-1
## Hardware information:
```
eeeeeeeeeeeeeeeeeeeeeee ---------------
eeeee eeeeeeeeeeee eeeee OS: elementary OS 5.0 Juno x86_64
eeee eeeee eee eeee Host: Latitude E7440 00
eeee eeee eee eeee Kernel: 4.15.0-36-generic
eee eee eee eee Uptime: 18 mins
eee eee eee eee Packages: 1765
ee eee eeee eeee Shell: bash 4.4.19
ee eee eeeee eeeeee Resolution: 1366x768
ee eee eeeee eeeee ee DE: Pantheon
eee eeee eeeeee eeeee eee WM: Mutter(Gala)
eee eeeeeeeeee eeeeee eee Terminal: io.elementary.t
eeeeeeeeeeeeeeeeeeeeeeee eeeee CPU: Intel i7-4600U (4) @ 3.300GHz
eeeeeeee eeeeeeeeeeee eeee GPU: Intel Haswell-ULT
eeeee eeeee Memory: 1375MiB / 7882MiB
```
## Other log output:
- libinput debug [debug.out](/uploads/6a6c4c8d7a61cdb2bdf0b1cc9433d441/debug.out)
- libinput record file [libnput.record.txt](/uploads/91e5a174c26545bf0e24dd11c7bb92b1/libnput.record.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.) -->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/237Improve hardcoded delay value for button scrolling2021-12-21T04:51:33ZHenré BothaImprove hardcoded delay value for button scrolling## Summary
When using button scrolling, a hardcoded delay of 200 milliseconds between button down and scroll events being emitted makes fast scrolling gestures feel clunky and sometimes fail entirely. Let's discuss what this timeout val...## Summary
When using button scrolling, a hardcoded delay of 200 milliseconds between button down and scroll events being emitted makes fast scrolling gestures feel clunky and sometimes fail entirely. Let's discuss what this timeout value should be.
## Feature details
When using button scrolling (where holding a chosen button down translates pointer movement into scroll events), there is a hardcoded delay of 200 milliseconds (in src/evdev.c) during which the pointer is immobilised, but scroll events are not yet emitted. This delay forms part of the design allowing the chosen button to perform both its normal function and the button scroll function. It acts to prevent minor mouse movement during what is intended to be a normal click from swallowing the click event and instead emitting scroll events. (It is likely that a pointing device will experience minor movement during a normal button press; that is what this delay is attempting to work around.)
200 milliseconds is a long time. I have used dedicated utils in the past to provide this functionality on other operating systems, and those utils do not attempt to preserve the button's original function, and thereby have no need of a delay. Using those utils, it's easy to press the scroll button and immediately begin scrolling, which feels quite natural. Attempting this gesture with the 200 ms delay in place is much more clunky; the intended scrolling often does not happen at all (for quick "one page" scroll flicks, which for me take less than 200 ms).
I discussed this a bit with @whot over email, and he suggested we could discuss perhaps changing the timeout length, as the 200 ms value was chosen seemingly arbitrarily and has never changed.
I've compiled libinput with the delay reduced to 50 ms, which feels fairly natural for scrolling, but starts to lose the intended "anti-jitter" effect. I'm not sure whether a value exists which would both enable natural scrolling gestures and preserve the button's original function. Perhaps we need to concretely determine _how much_ anti-jitter is needed?
## Affected Hardware
Any pointing devices that use button scrolling are affected.
The feature in its current state benefits devices such as mice, but devices such as trackpads and trackballs actually see little benefit because it is easy to press a button with absolutely no pointer movement.
## Implementation in Other Systems
Other utils typically don't attempt to preserve the button's original function, and so don't have a delay in place.
<!-- original email
I've compiled libinput reducing that delay from 200 ms to 50 ms and it feels very responsive for scrolling. I think what was tripping me up before, being used to instantaneous move->scroll translation, was I had gotten used to being able to hit the button, "spin" the ball, and release the button over a very short (< 250 ms) period to scroll roughly one page up/down. With the long delay, that entire "gesture" got swallowed. With 50 ms, I can still do that quite easily.
However, from my testing, this does kill the previous desired behaviour of buffering against minor mouse movements while clicking.
-->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/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/469Support "Add finger to click" on Trackpads2021-02-11T13:54:16ZKevin CoxSupport "Add finger to click" on Trackpads## Summary
It should be possible to click while moving the cursor by tapping the trackpad with additional fingers. For example I am using one finger to place my cursor on a link, then I can tap a second finger to select that link. I can...## Summary
It should be possible to click while moving the cursor by tapping the trackpad with additional fingers. For example I am using one finger to place my cursor on a link, then I can tap a second finger to select that link. I can then continue dragging the cursor with the first finger.
## Feature details
This feature allows the user to be more efficient with a trackpad as they don't need to stop moving the cursor before clicking, something that is currently a lot more awkward compared to using a mouse.
Basic use case:
1. Move cursor to a clickable target then, without lifting the first finger, tap a second finger to click that target. The cursor can continue to be dragged with the original finger.
Additional use cases:
1. Move cursor to a dragable target, add a second finger to "pick up" the target, move the target to the destination, then let go of the second finger to drop.
- Note: Currently adding a second finger will enter scroll mode, so this should be behind a preference.
2. Move the cursor using a finger, add 2 fingers to right click, add 3 fingers to middle click.
## Affected Hardware
Multi-touch trackpads.
## Implementation in Other Systems
Yes, this feature is implemented on the builtin Macbook trackpads and on the Apple Magic Trackpad.
/label ~enhancement ~"needs triage"