A new bug can be filed here: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=libinput
When reporting bugs against libinput, please follow the instructions below and provide the required data. This will speed up triage, resulting in a quicker bugfix.
First, try to identify the bug by reproducing it reliably. The more specific a bug description is, the easier it is to fix. The libinput debug-events helper tool can help identify whether the bug is in libinput at all. This tool is a direct hook to libinput without a desktop stack in between and can thus help to identify whether a bug is in libinput or in one of the higher layers. See the libinput debug-events section for information on this tool.
Triaging bugs
Some specific information is required, providing it enables the developers to get a clear picture of what the issue with your device is.
Always include the libinput version. Either the package version from your distribution or, when running from git: git log -n 1 HEAD or git describe HEAD. As a last resort: libinput-list-devices –version.
Include the current libinput settings for the device (if you are on X11). The current settings can be obtained with xinput list-props "your device
name". Use xinput list to obtain the device name.
Third, pick which device are you reporting a bug for:
- Reporting touchpad bugs
- Reporting mouse bugs
- Reporting keyboard bugs
- Reporting trackpoint bugs
- All other devices
Reporting touchpad bugs
When you file a bug, please attach the following information:
- a virtual description of your input device, see Recording devices with evemu. This is the most important piece of information, do not forget it!
- the output from udevadm info, see udev information for the device.
- the vendor model number of your laptop (e.g. "Lenovo Thinkpad T440s")
- and the content of
/sys/class/dmi/id/modalias. - the physical dimensions of your touchpad in mm
If you are reporting a bug related to button event generation:
- does your touchpad have (separate) physical hardware buttons or is the whole touchpad clickable?
- Are you using software buttons or clickfinger? See Clickpad software button behavior.
Reporting mouse bugs
When you file a bug, please attach the following information:
- a virtual description of your input device, see Recording devices with evemu. This is the most important piece of information, do not forget it!
- the vendor model number of the device (e.g. "Logitech M325")
- the output from udevadm info, see udev information for the device.
If the bug is related to the speed of the mouse:
- the resolution of the mouse as specified by the vendor (in DPI)
- the output of the mouse-dpi-tool (provided by libevdev)
Reporting keyboard bugs
When you file a bug, please attach the following information:
- a virtual description of your input device, see Recording devices with evemu. This is the most important piece of information, do not forget it!
Reporting trackpoint bugs
When you file a bug, please attach the following information:
- a virtual description of your input device, see Recording devices with evemu. This is the most important piece of information, do not forget it!
- the vendor model number of the device (e.g. "Logitech M325")
- the output from udevadm info, see udev information for the device.
All other devices
When you file a bug, please attach the following information:
- a virtual description of your input device, see Recording devices with evemu. This is the most important piece of information, do not forget it!
- the vendor model number of the device (e.g. "Sony Plastation3 controller")
udev information for the device
In many cases, we require the udev properties assigned to the device to verify whether device-specific quirks were applied. This can be obtained with `udevadm info /sys/class/input/eventX, with the correct event node for your device. An example output is below:
Recording devices with evemu
evemu records the device capabilities together with the event stream from the kernel. On our side, this allows us to recreate a virtual device identical to your device and re-play the event sequence, hopefully triggering the same bug.
evemu-record takes a /dev/input/eventX event node, but without arguments it will simply show the list of devices and let you select:
Select the device that triggers the issue, then reproduce the bug and Ctrl+C the process. The resulting recording, ("scroll.evemu" in this example) will contain the sequence required to reproduce the bug. If the bug fails to reproduce during recording, simply Ctrl+C and restart evemu-record. Always start the recording from a neutral state, i.e. without any buttons or keys down, with the position of the device in the neutral position, without touching the screen/touchpad.
- Note
- The longer the recording, the harder it is to identify the event sequence triggering the bug. Please keep the event sequence as short as possible.
To verify that the recording contains the bug, you can replay it on your device. For example, to replay the sequence recorded in the example above:
If the bug is triggered by replaying on your device, attach the recording to the bug report.
- Note
- libinput does not affect the evemu recording. libinput and evemu talk directly to the kernel's device nodes. An evemu recording is not influenced by the libinput version or whether a libinput context is currently active.
