doc/user: write an article explaining the different contexts

This is a common question I need to answer, let's make this a link I can
copy/paste instead.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>

1 files changed, 24 insertions, 0 deletions

diff --git a/doc/user/faqs.rst b/doc/user/faqs.rst
index b3afa8d2..f7dbc124 100644
--- a/doc/user/faqs.rst
+++ b/doc/user/faqs.rst
@@ -335,3 +335,27 @@ are more specialized (e.g. in-vehicle infotainment or IVI) can handle input
 devices directly but the compositor you want to use
 on your desktop needs an input stack that is more complex. And right now,
 libinput is the only input stack that exists for this use-case.
+
+.. _faq_separate_contexts:
+
+------------------------------------------------------------------------------
+Can I write a program to make libinput do $FOO
+------------------------------------------------------------------------------
+
+A common question is whether it's possible to write a program that can change
+libinput's behavior - specifically the libinput that is used inside the
+compositor. This indicates a misunderstanding of how libinput works:
+libinput is a library that converts kernel events into libinput events, much
+like ``sed`` reads data in, modifies it, and provides it to stdout.
+
+If ``sed`` is used by a shell-script, that script has full control over how
+``sed`` processes data. In this analogy, ``sed`` is libinput and the
+shell script is the compositor. It is not possible to write a program
+to modify the behavior of the ``sed`` instance used inside that shell script
+
+Writing a program that uses libinput is akin to writing a new script that
+invoke ``sed``. It will not have any effect on the original ``sed`` instance.
+
+The only way to modify libinput's behavior is to use the configuration options
+exposed by the respective compositor. Those affect the libinput context inside
+the compositor and thus have an effect on the input device behavior.