summaryrefslogtreecommitdiff
path: root/doc/user/faqs.rst
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/faqs.rst')
-rw-r--r--doc/user/faqs.rst24
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.