summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPeter Hutterer <peter.hutterer@who-t.net>2018-07-26 09:18:29 +1000
committerPeter Hutterer <peter.hutterer@who-t.net>2018-07-27 09:35:00 +1000
commitd6d208ab1a549fe1d50121b51a316baece9fc432 (patch)
tree6a819430a146f86ac50188f9a3675c069da2e83a
parent6d8b10153c5e6a187585adef00b25b1029213d14 (diff)
doc: move the Architecture blurb to the 'what is libinput' page
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>
-rw-r--r--README.md25
-rw-r--r--doc/what-is-libinput.dox34
2 files changed, 34 insertions, 25 deletions
diff --git a/README.md b/README.md
index e5e89fc8..3d0c5670 100644
--- a/README.md
+++ b/README.md
@@ -22,31 +22,6 @@ and the instructions on
[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
-----------
diff --git a/doc/what-is-libinput.dox b/doc/what-is-libinput.dox
index fd0f5b14..89b403e1 100644
--- a/doc/what-is-libinput.dox
+++ b/doc/what-is-libinput.dox
@@ -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
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.
+
*/