libinput issueshttps://gitlab.freedesktop.org/libinput/libinput/-/issues2024-03-27T19:40:20Zhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/983Libinput doesn't recognize Xbox controller, recognizes other controllers2024-03-27T19:40:20ZioletsgoLibinput doesn't recognize Xbox controller, recognizes other controllers## Summary
The handshake between the kernel recognizing exclusively an Xbox controller and Libinput recognizing it as a valid controller somehow gets lost; could be an upstream issue.
Plug In Xbox Controller on latest version of Libi...## Summary
The handshake between the kernel recognizing exclusively an Xbox controller and Libinput recognizing it as a valid controller somehow gets lost; could be an upstream issue.
Plug In Xbox Controller on latest version of Libinput on a Arch Linux KDE Plasma 6 desktop, feel the controller vibrate and the operating system play the "USB Device Paired" sound to signal a handshake taking place, type `libinput record`, notice xbox controller isn't in the list./
Plug in Switch Pro Controller using same cable, type `libinput record`, to be greeted with a list that includes the Switch Pro Controller
## Required information
- libinput version:
- 1.25.0
- hardware information:
```
OS: Arch Linux x86_64
Host: MS-7D54 1.0
Kernel: 6.8.1-arch1-1
Uptime: 14 mins
Shell: bash 5.2.26
DE: Plasma 6.0.2
WM: kwin
CPU: AMD Ryzen 7 5800X3D (16) @ 3.400GHz
GPU: AMD ATI Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT
```
The two attachments are snippit of journalctl -b where I unplugged and replugged the xbox controller and the same process done on the Switch Pro Controller, which is confirmed working on libinput's part.
[xbox.log](/uploads/98b9f61f87a074d55b220b6f5693cb67/xbox.log)
[Switch.log](/uploads/b56c02bf295a85a16e05b6ab97c28a32/Switch.log)https://gitlab.freedesktop.org/libinput/libinput/-/issues/982[Touchpad] The option "Disable While Typing" is not taken into account2024-03-25T11:04:04ZGérard[Touchpad] The option "Disable While Typing" is not taken into account## Summary
<!--
Summarize the bug encountered concisely. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html for
detailed instructions to report bugs
-->
Touchpad dwt deactivation is not taken into account by li...## Summary
<!--
Summarize the bug encountered concisely. See
https://wayland.freedesktop.org/libinput/doc/latest/reporting-bugs.html for
detailed instructions to report bugs
-->
Touchpad dwt deactivation is not taken into account by libinput
## Steps to reproduce
```
#include <fcntl.h>
#include <unistd.h>
#include <iostream>
#include <libinput.h>
#include <X11/Xlib.h>
int main()
{
struct libinput_interface interface;
struct udev* udev = udev_new();
interface.open_restricted =
[](const char* path, int flags, void* userdata) -> int {
flags |= O_CLOEXEC;
int fd = open(path, flags);
return fd;
};
interface.close_restricted = [](int fd, void* userdata) { close(fd); };
struct libinput* handle =
libinput_udev_create_context(&interface, nullptr, udev);
Display* dpy = XOpenDisplay(nullptr);
libinput_udev_assign_seat(handle, "seat0");
struct libinput_event* ev;
enum libinput_event_type evtype;
libinput_dispatch(handle);
while ((ev = libinput_get_event(handle))) {
evtype = libinput_event_get_type(ev);
switch (evtype) {
case LIBINPUT_EVENT_DEVICE_ADDED: {
if (struct libinput_device* dev = libinput_event_get_device(ev);
dev) {
if (libinput_device_has_capability(
dev, LIBINPUT_DEVICE_CAP_POINTER)) {
std::string deviceName = libinput_device_get_name(dev);
if (deviceName.find("Touchpad") != std::string::npos) {
std::cout << "device name: "
<< libinput_device_get_name(dev)
<< std::endl;
if (libinput_device_config_dwt_is_available(dev)) {
std::cout
<< "\tdwt is "
<< (libinput_device_config_dwt_get_enabled(
dev) == LIBINPUT_CONFIG_DWT_ENABLED
? "enabled"
: "disabled")
<< std::endl;
std::cout
<< "\tdefault dwt is "
<< (libinput_device_config_dwt_get_default_enabled(
dev) == LIBINPUT_CONFIG_DWT_ENABLED
? "enabled"
: "disabled")
<< std::endl;
}
}
}
}
}
default: break;
}
libinput_event_destroy(ev);
}
libinput_unref(handle);
udev_unref(udev);
return 0;
}
```
List of command lines I've made:
```
$> xinput | grep Touchpad
⎜ ↳ ELAN0674:00 04F3:3193 Touchpad id=11 [slave pointer (2)]
$> xinput list-props 11 | grep "Disable While Typing"
libinput Disable While Typing Enabled (356): 0
libinput Disable While Typing Enabled Default (357): 1
$> g++ main.cpp -lX11 -linput -ludev
$> ./a.out
device name: ELAN0674:00 04F3:3193 Touchpad
dwt is enabled
default dwt is enabled
```
<!-- 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.23
- hardware information: Ubuntu 23.10 Gnome X11
<!--
- `libinput record` output: do not paste, **attach** the file
- `libinput debug-events --verbose` output: do not paste, **attach the file**
-->
<!--
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/978Touchpad sometimes detects wrong number of fingers for both movement and clicks2024-03-28T21:10:36ZPhilippTouchpad sometimes detects wrong number of fingers for both movement and clicks## Summary
Sometimes my touchpad gets into a buggy state where it detects the wrong number of fingers, i.e 2 instead of 1 finger and it double clicks instead of single click, scroll instead of normal movement. Sometimes it even detects ...## Summary
Sometimes my touchpad gets into a buggy state where it detects the wrong number of fingers, i.e 2 instead of 1 finger and it double clicks instead of single click, scroll instead of normal movement. Sometimes it even detects 3 instead of 1 finger and makes a triple click / triple swipe instead of the single finger action.
Once it enters the wrongful state I can do single clicks and it will do a double click (opens up the context menu) or touch the touchpad and move my finger up and down, instead of moving the cursor it will scroll up and down. Same goes for the 3 finger mode, it will then do a triple swipe (and open up the workspace overview in Gnome) instead of regular cursor movement.
I can also consistently leave the wrongful state either with one or multiple triple clicks / triple swipes. Most of the time a single triple click / swipe is enough. After that the touchpad will work as expected until it gets back into the buggy state again.
It works on Windows 11, so I assume it is (probably?) not a hardware issue.
## Steps to reproduce
Happens randomly, I have not found a definitive way to reproduce it. But if I do some random triple and double clicks there is a chance it will change into the "wrong fingers state". The longer my laptop is powered on the more likely it happens. I had sessions that lasted a long time without the issue, but once it got into the wrong state, it will periodically do so.
## Required information
- libinput version: 1.25.0
- hardware information: Xiaomi Book Pro 16 2022
- touchpad: GXT7863:00 27C6:01E0 Touchpad
- OS: Ubuntu 24.04 (but I can also reproduce it on Ubuntu 23.10 and Manjaro/Fedora)
Some `libinput debug-events` log files:
- [start-debug-events-in-wrongful-state.txt](/uploads/c0722f92504e6febfea4b9f75b97cc7f/start-debug-events-in-wrongful-state.txt)
started `libinput debug-events` in wrongful state, there is NO pointer activity being logged. Only once I leave the wrongful state, the pointer activity is again being logged. The keyboard events are done inside the wrongful state, then I do some single clicks and movement which is not recognized by the tool. Afterwards I do a triple click and we go back to the normal state and the logging happens again.
- [start-debug-events-in-normal-state-return-with-triple-swipe.txt](/uploads/ad906bab98bb82921caaf1330160c2bf/start-debug-events-in-normal-state-return-with-triple-swipe.txt)
started `libinput debug-events` in normal state and did some stuff until it got into the wrongful state. Returning to the normal state with a triple swipe (assuming the GESTURE_SWIPE_BEGIN being it). Multiple clicks before the tripe swipe are actually single clicks.
- [start-debug-events-in-normal-state-return-with-jump.txt](/uploads/d28c1ce1b105a5981b7ff9c0b118a17c/start-debug-events-in-normal-state-return-with-jump.txt)
again started `libinput debug-events` in normal state and waited for the change to wrongful state. Returning to normal state with a triple swipe, this time jump happens. All the clicks before the jump are actually single clicks.
Some `libinput record` log files:
- [single-clicks-detected-as-double-clicks.txt](/uploads/5a19e2dd4235d5636e23d75a23a17af9/single-clicks-detected-as-double-clicks.txt)
Started the record in wrongful state and did some single clicks which are detected as double clicks.
- [single-clicks-normal.txt](/uploads/00b9a7d395471251c39dd9f666f65d35/single-clicks-normal.txt)
For comparison some single clicks in normal mode which are detected properly.
- [double-clicks-detected-as-triple-clicks.txt](/uploads/0cdd301b70943ab48dffbaf76371b21f/double-clicks-detected-as-triple-clicks.txt)
Started the record in wrongful state and did some double clicks which are detected as triple clicks.
- [double-clicks-normal.txt](/uploads/0b285168b42d9ad049596ba5223ccffc/double-clicks-normal.txt)
For comparison some double clicks in normal mode which are detected properly.
My touchpad edges: [touchpad-edges.txt](/uploads/d365bc2374bc55d87313f624872f4b0d/touchpad-edges.txt)
## Things I tried that did not help
- I tried several kernel parameters (i.e. i8042.noaux, i8042.reset, etc.) in different combinations
- Switching to X.org instead of wayland
- `modprobe -r hid_multitouch` followed by `modprobe -r hid_multitouch` resets the wrongful mode but it will come back againhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/971Dell Precision 7750 Touchpad MMB Delayed Press Event2024-02-16T23:51:50ZwaterlubberDell Precision 7750 Touchpad MMB Delayed Press Event## Summary
The physical middle mouse button on my Precision 7750 exhibits strange behavior when held down. Libinput successfully detects the button-down and button-up events from the kernel and timestamps them correctly, but refuses to ...## Summary
The physical middle mouse button on my Precision 7750 exhibits strange behavior when held down. Libinput successfully detects the button-down and button-up events from the kernel and timestamps them correctly, but refuses to "release" them until after the button is released. Effectively, MMB works to click or select things, but cannot be held down for _e.g._ CAD software or scrolling purposes.
Consider the following screenshots. The following is of "normal" LMB behavior (interestingly, this is on event11 and not event10, as the MMB is): the event for buton down is received, debouncing code runs, and libinput presents a "pointer button down" event. After release, the debouncing code again runs, and indicates release.
![image](/uploads/c21d1285bfc7bd8d8f4b9fc19c41017d/image.png)
The MMB does not present events until after it is released. (Note the copy-pasted text from when the MMB event reached the terminal application and triggered a paste).
![image](/uploads/0efefabf583bc6dae3abfd9b17be90e8/image.png)
Interestingly, libinput reports the correct start time for the button-down event - it just waits until the button-up event to send this information to the symbol.
## Steps to reproduce
- Environment on this machine was KDE Plasma Desktop on Wayland, with no special mouse configuration. `wev` mirrors the behavior, as does various "online mouse button tester" applications.
- KDE mouse config:
![image](/uploads/5fd4ff24f6cabcc8715aea4b8f031f3c/image.png)
![image](/uploads/66d9866416005fbd305dac78617b074b/image.png)
- Simply launch `sudo libinput debug-events --verbose --device=/dev/input/event10` and observe the unusual behavior. Of course, you may need a Precision 7750 to reproduce the bug, although it may also occur on other Dell devices, or perhaps with all I2C_HID mice.
## Required information
- libinput version: 1.25.0-1, Arch Linux x86_64 Build. [Pacman -Qi libinput](/uploads/ce641c62b39765b8cba26fa8e7c7a886/libinput_version.txt)
- Hardware: Dell Precision 7750. Touchpad identified as "Dell09c4:00 0488:120a Mouse". Appears to be I2C HID.
- `libinput record` output: [record_10.txt](/uploads/2127bdfc0a2e9f3cf979f7f8b93f407c/record_10.txt)
- Recording produced by holding button briefly for several cycles, then a few quick presses.
- `libinput debug-events --verbose` output: [debug.txt](/uploads/637b0e2facb29e62881824295eb403bb/debug.txt)
- Produced similarly to the record output.
- [udev information for event10](/uploads/3c8d3ed80dd50af97b9879defbfa55be/udev.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/967TouchPad not completely recognized by libinput and being reported as PS/2 mou...2024-03-06T00:31:25ZNiels van AertTouchPad not completely recognized by libinput and being reported as PS/2 mouse too on Dell Precision 3581## Summary
The TouchPad on a Dell Precision 3581 is not recognized completely correctly. It functions correctly (including 2-finger scrolling), but it's reported as a "VEN_0488:00 0488:104B Mouse". The mouse is reported twice too. Once a...## Summary
The TouchPad on a Dell Precision 3581 is not recognized completely correctly. It functions correctly (including 2-finger scrolling), but it's reported as a "VEN_0488:00 0488:104B Mouse". The mouse is reported twice too. Once as a "PS/2 Generic Mouse and once as a TouchPad. Once I set my mouse to "PS/2 Generic Mouse", then the pointer moves slow and choppy. Once I set my mouse to "VEN_0488:00 0488:104B Mouse" it moves at high speed and smooth.
## Steps to reproduce
Boot a recent Linux environment on a Dell Precision 3581 laptop (I'm using KDE on Wayland myself) and look at the mouse properties.
## Required information
- libinput version: 1.24.0
- hardware information: Dell Precision 3581.
- `libinput record` output: N/A
- `libinput debug-events --verbose` output:[libinput_debug-events_verbose_28012024_1735.txt](/uploads/3eaa727bcaccf6583a5d2a88a5a05cd6/libinput_debug-events_verbose_28012024_1735.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/966Two finger scoll does not transform to pinch2024-02-19T03:28:15ZFriso SmitTwo finger scoll does not transform to pinch## Summary
I'm finding it finnicky to pinch to zoom on my touchpad (HP zbook studio G5). I looked at the [touchpad gestures state machine](https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/doc/touchpad-gestures-state-machine....## Summary
I'm finding it finnicky to pinch to zoom on my touchpad (HP zbook studio G5). I looked at the [touchpad gestures state machine](https://gitlab.freedesktop.org/libinput/libinput/-/blob/main/doc/touchpad-gestures-state-machine.svg), which says that scoll gestures can be transformed to pinch gestures. I tried doing that, but didn't succeed.
## Steps to reproduce
- Start two-finger scroll.
- Keep fingers on touchpad, but try to pinch. The scroll does not transform to a pinch.
## Required information
- libinput version: 1.24.0
- hardware information: HP Zbook studio G5 - synaptics touchpad
[attempt-pinch.txt](/uploads/fe89efc8eec1060f57c97989dcd0f579/attempt-pinch.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/965Feature request: Allow rotating the axes for scroll wheel emulation2024-01-22T06:28:34ZNiklaus HoferFeature request: Allow rotating the axes for scroll wheel emulation## Summary
Libinput already supports mouse wheel emulation. It would be great if that could be amended with options to rotate the axes when doing mouse wheel emulation.
## Feature details
I use this feature on X11 with my trackballs. ...## Summary
Libinput already supports mouse wheel emulation. It would be great if that could be amended with options to rotate the axes when doing mouse wheel emulation.
## Feature details
I use this feature on X11 with my trackballs. Instead of moving the ball back and forth, I can move it sideways to scroll up/down. To achieve this, I use the bellow command:
```bash
xinput --set-prop 'Logitech USB Receiver Mouse' 'Evdev Wheel Emulation Axes' 5 4 0 0"
```
## Affected Hardware
Trackballs, mice.
## Implementation in Other Systems
This feature works well on Linux using `xinput` (see above)https://gitlab.freedesktop.org/libinput/libinput/-/issues/963Logitech G604 Missed Scroll Events When Switching Direction2024-02-19T03:29:51ZJoshuaBowermanLogitech G604 Missed Scroll Events When Switching Direction
## Summary
When the mouse is using high resolution scroll wheel events it misses the first event when switching directions.
Adding this quirk causes it to behave correctly:
```
[Logitech G604]
MatchName=*Logitech G604*
AttrEventCode=-R...
## Summary
When the mouse is using high resolution scroll wheel events it misses the first event when switching directions.
Adding this quirk causes it to behave correctly:
```
[Logitech G604]
MatchName=*Logitech G604*
AttrEventCode=-REL_WHEEL_HI_RES;-REL_HWHEEL_HI_RES;
```
## Steps to reproduce
With a G604 Scroll in 1 direction and then switch directions.
When switching directions scrolling noticeably pauses and skips 1 scroll event.
## Required information
<!-- Note: if your libinput version is older than the current stable version,
please reproduce with a current version instead -->
- libinput version: 1.24.0
- hardware information: ARCH On AMD64 with a Logitech G604 Mouse
- `libinput record` output: [no-quirk.yml](/uploads/b849a6d09c4fca214791bee824897c5b/no-quirk.yml) [with-quirk.yml](/uploads/f5f3c3d7e2c6b861eb134b2d674d3320/with-quirk.yml)
- `libinput debug-events --verbose` output:[debug-event-no-quirk.txt](/uploads/f0ea33b3c71101c12116a9a6185236ef/debug-event-no-quirk.txt) [debug-event-with-quirk.txt](/uploads/f576e7edb1307146dd60a51b5803a877/debug-event-with-quirk.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/961Flickering cursor and jumping all over2024-01-08T07:43:47ZWambuguFlickering cursor and jumping all over## Summary
## Steps to reproduce
## Required information
- libinput version:1.24.0
- hardware information:HP EliteBook 840 G5 archlinux
- `libinput record` output:
[recording.yml](/uploads/2f5f2619e857ba9e4e4fa9a5161881cd/recording...## Summary
## Steps to reproduce
## Required information
- libinput version:1.24.0
- hardware information:HP EliteBook 840 G5 archlinux
- `libinput record` output:
[recording.yml](/uploads/2f5f2619e857ba9e4e4fa9a5161881cd/recording.yml)
- `libinput debug-events --verbose`
[recordings.txt](/uploads/f83423e7ad6dbd2711310985bd3d7752/recordings.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/960Tapping should be enabled by default on devices where tapping is the only met...2024-01-10T04:04:14ZPayton QuinnTapping should be enabled by default on devices where tapping is the only method to trigger button clicks. But it isn't for device ELAN0406:00 04F3:30A6## Summary
From the libinput documentation: "Tapping is enabled by default on devices where tapping is the only method to trigger button clicks. This includes devices without physical buttons such as touch-capable graphics tablets."
How...## Summary
From the libinput documentation: "Tapping is enabled by default on devices where tapping is the only method to trigger button clicks. This includes devices without physical buttons such as touch-capable graphics tablets."
However, on my laptop tapping is the only method to trigger button clicks, and yet it's disabled by default on a variety of desktop environments.
## Steps to reproduce
Install a desktop environment on a device with
N: Name="ELAN0406:00 04F3:30A6 Touchpad"
(many razer devices)
Observe that tap to click is disabled by default
<!-- How to reproduce the issue on a developer machine - this is very important -->
## Required information
- libinput version: 1.24.0
- hardware information: Razer Blade 15 2019 Base
- `libinput record` output: libinput: record is not installedhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/959Touchpad on Dell XPS 9380 overly sensitive (DELL08AF:00 06CB:76AF Touchpad)2024-01-09T22:35:18ZFritz WeberingTouchpad on Dell XPS 9380 overly sensitive (DELL08AF:00 06CB:76AF Touchpad)## Summary
The tap threshold on the Dell touchpad in my XPS 9380 laptop is extremely low. Even the slightest glance with a finger or palm is enough to register as a tap, although you can barely feel it. Since my writsts rest to both sid...## Summary
The tap threshold on the Dell touchpad in my XPS 9380 laptop is extremely low. Even the slightest glance with a finger or palm is enough to register as a tap, although you can barely feel it. Since my writsts rest to both sides of the touchpad, my palms or the base of my thumbs will sometimes brush the pad when reaching for letters in the middle of the keyboard.
This makes typing hazardous while the mouse pointer is over a text field, because the input cursor can move at any time. But the worst case is when are thinking for a moment and then start a new sentence, because the "disable while typing" feature is not yet active before typing the first letter, and the Shift key causes you to select a whole block of text, which you then overwrite with the first capital letter of the sentence.
Is there any way to configure the tap threshold via i2c inside the touchpad device? Because according to `sudo libinput measure touchpad-pressure`, the device does not report pressure values to userspace.
## Steps to reproduce
Put your finger on the touchpad as lightly as possible in a glancing motion.
No way to reproduce without access to the hardware, I'm afraid.
Let me know if I can help somehow.
## Required information
- libinput version: 1.24.0
- hardware information: XPS 9380, DELL08AF:00 06CB:76AF Touchpad
- `libinput record` output: [record.txt](/uploads/823532bb02b39a1364ff5649bc2e0653/record.txt)
- `libinput debug-events --verbose` output: [events.txt](/uploads/5d7f934d72077bfcd4d7b83a3a0b70e8/events.txt)
Both `record.txt` and `events.txt` show the same sequence of events:
1. A very light glancing touch with the index finger (barely noticeable)
2. A more determined, forceful tap with the index finger (quick tap, bouncing back)
3. Deliberately pressing down with the index finger for a short duration (longer than a tap, not pressing the clicky button)
```
$ sudo libinput quirks list /dev/input/event10
ModelTouchpadVisibleMarker=1
AttrMscTimestamp=watch
```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/952RFC: Support tablet tool pressure curves?2024-01-17T03:37:43ZPeter HuttererRFC: Support tablet tool pressure curves?This is primarily motivated by [this gnome-control-center issue](https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2493) to request adjustable min/max thresholds for the pen, in particular the min threshold part. The minimum t...This is primarily motivated by [this gnome-control-center issue](https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2493) to request adjustable min/max thresholds for the pen, in particular the min threshold part. The minimum threshold is a *user specific configuration* to set the pressure required for a tip down event to happen.
libinput currently hardcodes when a tip down event happens (5% of range). If we adjust the minimum thresholds libinput needs to adjust the tip down handling accordingly. So if we add min threshold support, we need to have this exposed by libinput, e.g. as `libinput_device_config_tablet_tool_set_min_threshold()`.
Now the argument is that it would be more useful to shove max threshold *and* pressure curve into libinput as well. Technically this isn't needed since neither of those affect anything else in libinput but it makes for a nicer API and better consistency.
A possible API could be:
```
libinput_device_config_tablet_tool_set_pressurecurve(tool, A, B, C, D)
```
where:
- `A` is `x/0.0` and defines the minimum pressure threshold.
- `B` and `C` are `x/y` in the range of `[0.0, 1.0]` and define two control points on the cubic bezier `ABCD`
- Notably the Windows driver requires `B == C` but this seems to be primarily for a simpler GUI, there's no mathematical requirement for this
- `D` is is `x/1.0` and defines the maximum pressure threshold
This curve would give us min/max threshold handling as well as the pressure curve between these two.
I've always maintained that the pressure curve should be ideally handled by the application (to have per-application curves) and if not by the compositor but not by libinput. Having this handled in apps is unlikely to ever happen. Having it in the compositor is what happens today Windows, Macos and Linux and with application-specific profiles are handled through focus tracking and then applying a new pressure curve.
So the argument now is: if we need to add a new API anyway for the min threshold handling it's probably better to have the whole handling of pressure curves in libinput rather than just the min threshold and leave the bits above it to the compositor. This would remove a bunch of code from the compositors and unify it in one implementation.
The only technical downside is that if for some reason an application needs the unmodified raw pressure that one is no longer available. I don't know if there's a use-case for this though.
Thoughts?
Side note: this would also provide a work around offset bugs like #834 which are more difficult to solve heuristically.
cc @JoseExposito @carlosg @jadahl @jigpu @pinglinuxhttps://gitlab.freedesktop.org/libinput/libinput/-/issues/951Multimedia keys not working anymore on LiteOn Lenovo Calliope USB Keyboard2023-12-13T16:15:29ZSamuel F BaggenMultimedia keys not working anymore on LiteOn Lenovo Calliope USB KeyboardFollowing this bug report thread: https://gitlab.freedesktop.org/libinput/libinput/-/issues/745#note_2173124
I have the same issue in recent versions of libinput. The version of libinput is 1.22, upgrading it to 1.23 (debian testing or ...Following this bug report thread: https://gitlab.freedesktop.org/libinput/libinput/-/issues/745#note_2173124
I have the same issue in recent versions of libinput. The version of libinput is 1.22, upgrading it to 1.23 (debian testing or unstable) still have the same issue, I updated the packages libinput10, libinput-bin, libinput-tools, and even xserver-xorg-input-libinput, but the multimedia keys still doesn't work.
There's some debug events information:
```
event2 - LiteOn Lenovo Calliope USB Keyboard: is tagged by udev as: Keyboard
event2 - LiteOn Lenovo Calliope USB Keyboard: device is a keyboard
event3 - LiteOn Lenovo Calliope USB Keyboard System Control: is tagged by udev as: Keyboard
event3 - LiteOn Lenovo Calliope USB Keyboard System Control: device is a keyboard
event4 - LiteOn Lenovo Calliope USB Keyboard Consumer Control: is tagged by udev as: Keyboard Joystick
event4 - LiteOn Lenovo Calliope USB Keyboard Consumer Control: device is a joystick or a gamepad, ignoring
```
_Note: the command libinput doesn't runs from user (permission denied), I need to use "sudo" for it_
Some photos of the keyboard, just in case to see which keys / multimedia keys it has:
* https://ibb.co/znRt2s1
* https://ibb.co/gSn3j4whttps://gitlab.freedesktop.org/libinput/libinput/-/issues/948Stylus-touch arbitration does not ignore touch inputs on pen hovering.2023-11-17T05:39:16ZRayJWStylus-touch arbitration does not ignore touch inputs on pen hovering.## Summary
When using the "Lenovo Precision Pen 2 (2023)" on a "Lenovo Yoga 9 14IAP7" the stylus-touch arbitration only ignores touch inputs when the pen is touching the screen, not on the hover event though, despite being correctly rec...## Summary
When using the "Lenovo Precision Pen 2 (2023)" on a "Lenovo Yoga 9 14IAP7" the stylus-touch arbitration only ignores touch inputs when the pen is touching the screen, not on the hover event though, despite being correctly recognized. This is making writing with the pen much more difficult as the screen can erratically move around due to the palm generating touch events dragging the screen while lifting the pen for e.g. starting to write a new word.
In the attached log, I constantly made touch inputs and there one can see, that they are correctly ignored as long as the pressure is non-zero (pen is down on the screen). Once the pen is hovering though (pressure 0.00) the touch events are starting to get logged.
## Steps to reproduce
1. Bring the pen into proximity of the screen, so the hover is correctly recognized.
2. Touch the screen at the same time.
3. Touch should still work despite stylus-touch arbitration being enabled.
## Required information
- libinput version: libinput-1.24.0-1.fc39.x86_64
- hardware information: Lenovo Yoga 9 14IAP7
- `libinput record` output: [stylus-touch-arbitration.yml](/uploads/52239b3fa109a87f4803a08dbb3d6d1c/stylus-touch-arbitration.yml)
- `libinput debug-events --verbose` output: [debug-output.log](/uploads/fc631e79df052d8c28414420671ad865/debug-output.log)https://gitlab.freedesktop.org/libinput/libinput/-/issues/946Touchpad on Lenovo Ideapad too sensitive to pressure2023-11-26T23:32:25ZLuigi BaldoniTouchpad on Lenovo Ideapad too sensitive to pressureI'm using a Lenovo Idepad 3 15ADA05 and since switching to Wayland, inadvertent clicks have become a daily occurrence.
I followed [the guide](https://wayland.freedesktop.org/libinput/doc/latest/touchpad-pressure-debugging.html) regarding...I'm using a Lenovo Idepad 3 15ADA05 and since switching to Wayland, inadvertent clicks have become a daily occurrence.
I followed [the guide](https://wayland.freedesktop.org/libinput/doc/latest/touchpad-pressure-debugging.html) regarding pressure and these were the results:
```
$ libinput quirks list /dev/input/event0
AttrKeyboardIntegration=internal
$ sudo libinput measure touchpad-pressure
Using MSFT0001:00 2808:0101 Touchpad: /dev/input/event13
This device does not have the capabilities for pressure-based touch detection.
Details: Device does not have ABS_PRESSURE or ABS_MT_PRESSURE
```
Is there anything to be done?https://gitlab.freedesktop.org/libinput/libinput/-/issues/945jumping cursor when using touchpad on Lenovo thinkpad2023-11-02T10:00:02ZBalthasar Schlotmannjumping cursor when using touchpad on Lenovo thinkpad## Summary
When I use the touchpad of this laptop the cursor randomly jumps. The jumps can be very small, but sometimes the touchpad basically becomes unusable for a few minutes, because the curser jumps uncontrollably when I do any mov...## Summary
When I use the touchpad of this laptop the cursor randomly jumps. The jumps can be very small, but sometimes the touchpad basically becomes unusable for a few minutes, because the curser jumps uncontrollably when I do any movement. It seems there is a known issue with Lenovo touchpads, but the linked page in the documentation recommends to report issues regardless. I think all required hardware documentation is in the libinput recording, but please tell me if anything is missing. It is somewhat difficult to record this, because a previous jumping does not necessarily mean there will be another jump soon afterwards and not touching the touchpad seems to reduce the issue a bit, but I think the attached recording demonstrates the issue well.
## Steps to reproduce
It happens randomly multiple times a day and I do not know how to trigger it specifically, but it is frequent enough that I could get a new recording of the issue within an hour. I also do not need to use two fingers, like in the other Lenovo bug report. This behaviour happens when using a single finger to move the cursor.
## Required information
- libinput version: 1.21.0
- hardware information: SynPS/2 Synaptics TouchPad
- `libinput record` output: [pointer_jump.yaml](/uploads/8ddcbc4eec7875dda6947461a7a5940b/pointer_jump.yaml)
Journalctl output:
```
kwin_libinput: Libinput: event16 - SynPS/2 Synaptics TouchPad: kernel bug: Touch jump detected and discarded.
See https://wayland.freedesktop.org/libinput/doc/1.21.0/touchpad-jumping-cursors.html for details
```
The above link recommends filing bug reports, even though similar issues have been recorded before, which is why I report it.
Later:
`kwin_libinput: Libinput: event16 - SynPS/2 Synaptics TouchPad: WARNING: log rate limit exceeded (5 msgs per 24h). Discarding future messages`.
Another message that only appeared once and might not be related:
`kwin_libinput: Libinput: event4 - SynPS/2 Synaptics TouchPad: client bug: event processing lagging behind by 23ms, your system is too slow`https://gitlab.freedesktop.org/libinput/libinput/-/issues/944SpeedLink SWAY Trackpad: Buttons are registered, but not propagated2023-10-31T09:26:36ZBernhard "HotKey" SlawikSpeedLink SWAY Trackpad: Buttons are registered, but not propagated## Summary
The "SpeedLink SWAY Trackpad" is an inexpensive USB multitouch touchpad. When connecting it, pointer movements work fine, but neither the physical buttons (left / right), nor tapping or dragging works as expected (i.e.: nothi...## Summary
The "SpeedLink SWAY Trackpad" is an inexpensive USB multitouch touchpad. When connecting it, pointer movements work fine, but neither the physical buttons (left / right), nor tapping or dragging works as expected (i.e.: nothing happens).
This issue seems to be present in some shape or form [since at least 2020](https://elementaryos.stackexchange.com/questions/26422/can-not-click-on-a-touchpad).
**Update**: The problem only occurs inside the desktop session. **At the login screen the buttons all work correctly!** So it seems to be a default-configuration issue for that device.
## Steps to reproduce
Attach the SWAY Trackpad using USB. The device is registered as "iTouch Pad iTouch Pad Consumer Control" and "iTouch Pad iTouch Pad Mouse" (Vendor 0x062a, Product 0x2901).
Moving the pointer works, but neither the hardware buttons, nor tapping or tap-and-hold results in any events in the OS.
**However**, running `libinput debug-events`, `xinput --query-state` or `hid-recorder` correctly reports the current state of the buttons, even for tap-and-hold (but not for multi-touch gestures). So, the buttons are **read correctly** from the device, but do not **propagate correctly** to the rest of the OS or get filtered in some way. Running `xev` does not report any button events, only motion events.
I am aware that this might not be a problem with libinput itself, but could be a "quirk" or other integration issue on a higher level. But, unfortunately, I do not know how to continue my debugging efforts from here. So any help would be appreciated!
## Required information
- libinput version: 1.20.0-1ubuntu0.3
- hardware information: idVendor=062a, idProduct=2901, bcdDevice=0.02 ("Speedlink SWAY Trackpad" / "MosArt Semiconductor Corp. iTouch Pad")
- [libinput record output](/uploads/1fd467c60a2acb63aa656beafdaf2ba6/libinput_record.txt)
- [libinput debug-events --verbose output](/uploads/110520e2f8c5de811e083bf64e68d79b/libinput_debug-events.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/935Nuvision Solo 10 Draw: Touchscreen stops working after using pen.2023-09-25T10:26:59ZLanceNuvision Solo 10 Draw: Touchscreen stops working after using pen.## Summary
I have a Nuvision Solo 10 Draw running Arch Linux and Gnome 45.rc from the Gnome Unstable repo https://codeberg.org/fabiscafe/fcgu After boot the touchscreen works great until after the stylus is used. After which only the st...## Summary
I have a Nuvision Solo 10 Draw running Arch Linux and Gnome 45.rc from the Gnome Unstable repo https://codeberg.org/fabiscafe/fcgu After boot the touchscreen works great until after the stylus is used. After which only the stylus input works and the touchscreen appears disabled and not working. A reboot is required at this point to get touch working again.
I cannot be sure if this is a Gnome or Mutter issue. I have one other device that uses the same type of stylus this device does, a Surface Go 2, which I have running the exact same software. For that device stylus and touch issues were finally fixed from this issue https://gitlab.gnome.org/GNOME/mutter/-/issues/3016 and resulting merge request https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3261
## Steps to reproduce
Bring stylus to tablet, observe that after this point finger touches do nothing even when the stylus is out of range. Continue to observe that the stylus still works to interact.
## Required information
- libinput version: 1.24.0
- hardware information: Nuvision Solo 10 Draw (TMAX TM101W610L), Intel Atom x5-Z8300, 2GB RAM, 32GB eMMC with expandable Micro SD card slot.
- `libinput record` output:[record_stylus.txt](/uploads/e10dfd7148c8fe143a52d9af413daa94/record_stylus.txt) [record_touchscreen.txt](/uploads/dfa4f259c33d5b4f05f60a388ea71e52/record_touchscreen.txt) [record_event4_unknown.txt](/uploads/e8c262056639875bbc6e3bbdd1d815d2/record_event4_unknown.txt) [record_event5_unknown.txt](/uploads/cfb6b211e5cf0892976fe4f7ad0bac23/record_event5_unknown.txt)
- `libinput debug-events --verbose` output:[libinput-debug-verbose.txt](/uploads/886518fb702672108d470976d149e044/libinput-debug-verbose.txt)https://gitlab.freedesktop.org/libinput/libinput/-/issues/922Forcepad click force and haptic feedback strength settings2023-08-07T06:05:40ZRadovan BlažekForcepad click force and haptic feedback strength settingsHello everyone,
Apple Magic Trackpad (at least on the 14" M1 Macbook Pro) has two clicking modes:
- Click and the haptic feedback is handled by the firmware (Autonomous click mode)
- Click and the haptic feedback is handled by the OS (H...Hello everyone,
Apple Magic Trackpad (at least on the 14" M1 Macbook Pro) has two clicking modes:
- Click and the haptic feedback is handled by the firmware (Autonomous click mode)
- Click and the haptic feedback is handled by the OS (Host click mode)[^1]
The force needed for a click and the strength of the haptic feedback for the autonomous click mode is configurable. However, I have not found any existing interface for a config like this. Do you have any ideas, opinions or pointers how to handle this?
Currently hid-magicmouse sets INPUT_PROP_BUTTONPAD for the touchpad. I got a hint[^2] that we could introduce INPUT_PROP_FORCEPAD and a new abstraction which would allow libinput to set the click settings.
The ideal end result would be that I could change the click strength using for example the KDE touchpad settings as easily as in macOS.
---
[^1]: Currently on Linux I think almost everyone uses autonomous click mode. I have found just one example where the host click functionality is implemented in an out-of-tree branch of the hid-magicmouse driver: https://github.com/nexustar/linux-hid-magicmouse
[^2]: https://oftc.irclog.whitequark.org/asahi-dev/2023-08-06#1691285404-1691290491;