fdo-mirrors/libinput
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libinput.git synced 2026-03-22 01:00:37 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

doc: update the FAQ entry with how config options are stored

Browse source 
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer 2017-01-27 14:34:39 +10:00
parent 6ef816b4f5
commit aae997e60e
1 changed files with 14 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
doc/faqs.dox
View file

@ -40,12 +40,20 @@ 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.
In a GNOME X.Org stack a user would usually toggle an option in
the gnome-control-center which adjusts a gsettings entry. That change is
picked up by gnome-settings-daemon and applied to the device by adjusting
input device properties that the xf86-input-libinput driver provides.
The input device property changes map to the respective libinput
configuration options.
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).
@dotfile libinput-stack-gnome.gv