Table of Contents
- My mouse moves too fast, even at the slowest setting
- Why isn't touchpad tap-to-click enabled by default
- Why does my touchpad lose track of touches
- Kinetic scrolling does not work
- Is libinput GPL-licensed?
- Where is the configuration stored?
- How do I configure my device on Wayland?
- How do I configure my device on X?
- Why don't synclient and syndaemon work with libinput?
- How to apply hwdb changes
Frequently asked questions about libinput.
This is a symptom of high-dpi mice (greater than 1000dpi). These devices need a udev hwdb entry to normalize their motion. See Normalization of relative motion for a detailed explanation.
The most common cause for this is an incorrect pressure threshold range. See Touchpad pressure-based touch detection for more info.
The X.Org synaptics driver implemented kinetic scrolling in the driver. It measures the scroll speed and once the finger leaves the touchpad the driver keeps sending scroll events for a predetermined time. This effectively provides for kinetic scrolling without client support but triggers an unfixable bug: the client cannot know that the events are from a kinetic scroll source. Scroll events in X are always sent to the current cursor position, a movement of the cursor after lifting the finger will send the kinetic scroll events to the new client, something the user does not usually expect. A key event during the kinetic scroll procedure causes side-effects such as triggering zoom.
libinput does not implement kinetic scrolling for touchpads. Instead it provides the libinput_event_pointer_get_axis_source() function that enables callers to implement kinetic scrolling on a per-widget basis, see Scroll sources.
No, libinput is MIT licensed. The Linux kernel header file linux/input.h in libinput's tree is provided to ensure the same behavior regardless of which kernel version libinput is built on. It does not make libinput GPL-licensed.
libinput does not store configuration options, it is up to the caller to manage these and decide which configuration option to apply to each device. This must be done at startup, after a resume and whenever a new device is detected.
One commonly used way to configure libinput is to have the Wayland compositor expose a compositor-specific configuration option. For example, in a GNOME stack, the gnome-control-center modifies dconf entries. These changes are read by mutter and applied to libinput. Changing these entries via the gsettings commandline tool has the same effect.
Another commonly used way to configure libinput is to have xorg.conf.d snippets. When libinput is used with the xf86-input-libinput driver in an X.Org stack, these options are read on startup and apply to each device. Changing properties at runtime with the xinput commandline tool has the same effect.
In both cases, the selection of available options and how they are exposed depends on the libinput caller (e.g. mutter or xf86-input-libinput).
This has an effect on the availability of configuration options: if an option is not exposed by the intermediary, it cannot be configured by the client. Also some configuration options that are provided by the intermediary may not be libinput-specific configuration options.
See Where is the configuration stored? Use the configuration tool provided by your desktop environment (e.g. gnome-control-center) or direct access to your desktop environment's configuration storage (e.g. gsettings).
$> cat /etc/X11/xorg.conf.d/99-libinput-custom-config.conf Section "InputClass" Identifier "something to identify this snippet" MatchDriver "libinput" MatchProduct "substring of the device name" Option "some option name" "the option value" EndSection
The identifier is merely a human-readable string that shows up in the log file. The MatchProduct line should contain the device name or a substring of the device name that the snippet should apply to. For a full list of option names and permitted values, see the libinput man page. xorg.conf.d snippets like the above apply to hotplugged devices but can be overwritten at runtime by desktop tools. Multiple snippets may be placed into the same file.
For run-time configuration and testing, the xinput debugging tool can modify a devices' properties. See the libinput man page for supported property names and values. Usually, an invocation looks like this:
$> xinput set-prop "the device name" "the property name" value [value2] [value3]
- Changes performed by xinput do not persist across device hotplugs. xinput is considered a debugging and testing tool only and should not be used for permanent configurations.
Synclient and syndaemon rely on X input device properties that are specific to the xf86-input-synaptics X.Org input driver. Both were written when the synaptics driver was the only commmon touchpad driver in existence. They assume that if the properties aren't available, no touchpad is available either. The xf86-input-libinput X.Org input driver does not export these driver-specific properties, synclient/syndaemon will thus not detect the touchpad and refuse to work. Other tools that rely on synclient/syndaemon or those same properties also do not work with xf86-input-libinput.
See also the blog posts The definitive guide to synclient and The future of xinput, xmodmap, setxkbmap, xsetwacom and other tools under Wayland
Sometimes users are asked to test updates to the udev hwdb or patches that include a change to the hwdb.
If you are testing a patch with a hwdb update, the file will be installed in the correct location. User-specific (i.e. user-written) hwdb entries for testing and debugging must be in
/etc/udev/hwdb.d/99-filename.hwdb. You may rename the
filename portion to something more useful, but make sure you keep the
.hwdb suffix. Do not modify files or save files in
Figure out the event node name of your device. Run
sudo evemu-describe with no arguments to get a list. If your device is
/dev/input/event4, your event node name is
event4 and you will need to replace that in the commands below.
Rebuild the hwdb and load the new set on your device:
sudo udevadm hwdb --update sudo udevadm trigger /sys/class/input/eventX sudo udevadm test /sys/class/input/eventX
With the event node matching your device. Make sure the udev property appears (or does not appear, whichever applies) in the output of the test command.
Once the output matches expectations, restart X or your Wayland compositor or reboot.