fdo-mirrors/libinput
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/libinput/libinput.git synced 2025-12-20 12:40:05 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

doc: move the Architecture blurb to the 'what is libinput' page

Browse source 
The vast majority of ppl reading the README is unlikely to care about this,
but they do care about the Wayland vs X.Org situation so let's split this up.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer 2018-07-26 09:18:29 +10:00
parent 6d8b10153c
commit d6d208ab1a
2 changed files with 34 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
README.md
View file

@ -22,31 +22,6 @@ and the instructions on
[reporting bugs](https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html). [reporting bugs](https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html).
Architecture
------------
libinput is not used directly by applications. Think of it more as a device
driver than an application library. It is used by the xf86-input-libinput
X.Org driver or Wayland compositors. The typical software stack for a system
running Wayland is:
@dotfile libinput-stack-wayland.gv
The Wayland compositor may be Weston, mutter, KWin, etc. Note that
Wayland encourages the use of toolkits, so the Wayland client (your
application) does not usually talk directly to the compositor but rather
employs a toolkit (e.g. GTK) to do so. The Wayland client does not know
whether libinput is in use.
The simplified software stack for a system running X.Org is:
@dotfile libinput-stack-xorg.gv
libinput is not employed directly by the X server but by the
xf86-input-libinput driver instead. That driver is loaded by the server
on demand, depending on the xorg.conf.d configuration snippets. The X client
does not know whether libinput is in use.
Source code Source code
----------- -----------

34
doc/what-is-libinput.dox
View file

@ -55,4 +55,38 @@ are handled. Instead, it takes best practice and the common use-cases and
provides it in an easy-to-consume package for compositors or other processes provides it in an easy-to-consume package for compositors or other processes
that need those interactions typically expected by users. that need those interactions typically expected by users.
@section libinput-wayland libinput and Wayland
libinput is not used directly by Wayland applications, it is an input stack
used by the compositor. The typical software stack for a system running
Wayland is:
@dotfile libinput-stack-wayland.gv
The Wayland compositor may be Weston, mutter, KWin, etc. Note that
Wayland encourages the use of toolkits, so the Wayland client (your
application) does not usually talk directly to the compositor but rather
employs a toolkit (e.g. GTK) to do so. The Wayland client does not know
whether libinput is in use.
libinput is not a requirement for Wayland or even a Wayland compositor.
There are some specialized compositors that do not need or want libinput.
@section libinput-xorg libinput and X.Org
libinput is not used directly by X applications but rather through the
custom xf86-input-libinput driver. The simplified software stack for a
system running X.Org is:
@dotfile libinput-stack-xorg.gv
libinput is not employed directly by the X server but by the
xf86-input-libinput driver instead. That driver is loaded by the server
on demand, depending on the xorg.conf.d configuration snippets. The X client
does not know whether libinput is in use.
libinput and xf86-input-libinput are not a requirement, the driver will only
handle those devices explicitly assigned through an xorg.conf.d snippets. It
is possible to mix xf86-input-libinput with other X.Org drivers.
*/ */