diff --git a/doc/building.dox b/doc/building.dox
index 5698fd46..726a3db9 100644
--- a/doc/building.dox
+++ b/doc/building.dox
@@ -60,13 +60,13 @@ $> meson --prefix=....
To verify the install worked correctly, check that libinput.so.x.x.x is in
the library path and that all symlinks point to the new library.
-
+@verbatim
$> ls -l /usr/lib64/libinput.*
-rwxr-xr-x 1 root root 946 Apr 28 2015 /usr/lib64/libinput.la
lrwxrwxrwx 1 root root 19 Feb 1 15:12 /usr/lib64/libinput.so -> libinput.so.10.13.0
lrwxrwxrwx 1 root root 19 Feb 1 15:12 /usr/lib64/libinput.so.10 -> libinput.so.10.13.0
-rwxr-xr-x 1 root root 204992 Feb 1 15:12 /usr/lib64/libinput.so.10.13.0
-
+@endverbatim
@subsection reverting_install Reverting to the system-provided libinput package
@@ -101,10 +101,10 @@ a manually built libinput may cause SELinux denials. This usually manifests
when gdm does not start because it is denied access to libinput. The journal
shows a log message in the form of:
-
+@verbatim
May 25 15:28:42 localhost.localdomain audit[23268]: AVC avc: denied { execute } for pid=23268 comm="gnome-shell" path="/usr/lib64/libinput.so.10.12.2" dev="dm-0" ino=1709093 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
May 25 15:28:42 localhost.localdomain org.gnome.Shell.desktop[23270]: /usr/bin/gnome-shell: error while loading shared libraries: libinput.so.10: failed to map segment from shared object
-
+@endverbatim
The summary of this error message is that gdm's gnome-shell runs in the
```system_u:system_r:xdm_t``` context but libinput is installed with the
@@ -140,21 +140,21 @@ libinput```
Fedora 22 and later: ```sudo dnf builddep libinput```
RHEL/CentOS/Fedora 21 and earlier: ```sudo yum-builddep libinput```
openSUSE:
-
+@verbatim
$> sudo zypper modifyrepo --enable `zypper repos | grep source | awk '{print $5}'`
$> sudo zypper source-install -d libinput10
$> sudo zypper install autoconf automake libtool
$> sudo zypper modifyrepo --disable `zypper repos | grep source | awk '{print $5}'`
-
+@endverbatim
Arch:
-
+@verbatim
$> sudo pacman -S asp
$> cd $(mktemp -d)
$> asp export libinput
$> cd libinput
$> makepkg --syncdeps --nobuild --noextract
-
+@endverbatim
diff --git a/doc/faqs.dox b/doc/faqs.dox
index b9c12df3..6d0c2977 100644
--- a/doc/faqs.dox
+++ b/doc/faqs.dox
@@ -98,7 +98,7 @@ See @ref faq_config_options If your desktop environment does not provide a
graphical configuration tool you can use an
xorg.conf.d snippet.
Usually, such a snippet looks like this:
-
+@verbatim
$> cat /etc/X11/xorg.conf.d/99-libinput-custom-config.conf
Section "InputClass"
Identifier "something to identify this snippet"
@@ -106,7 +106,7 @@ Section "InputClass"
MatchProduct "substring of the device name"
Option "some option name" "the option value"
EndSection
-
+@endverbatim
The identifier is merely a human-readable string that shows up in the log
file. The MatchProduct line should contain the device name or a substring of
@@ -123,9 +123,9 @@ debugging tool can modify a devices' properties. See the
libinput man page
for supported property names and values. Usually, an invocation looks like
this:
-
+@verbatim
$> xinput set-prop "the device name" "the property name" value [value2] [value3]
-
+@endverbatim
@note
Changes performed by xinput do not persist across device hotplugs. xinput is
@@ -179,14 +179,14 @@ reporting_bugs "file a bug".
@section faq_tablet_capabilities My tablet doesn't work
If you see the message
-
+@verbatim
libinput bug: device does not meet tablet criteria. Ignoring this device.
-
+@endverbatim
or the message
-
+@verbatim
missing tablet capabilities [...] Ignoring this device.
-
+@endverbatim
your tablet device does not have the required capabilities to be treated as
a tablet. This is usually a problem with the device and the kernel driver.
diff --git a/doc/tablet-support.dox b/doc/tablet-support.dox
index 054ef570..bd08baf6 100644
--- a/doc/tablet-support.dox
+++ b/doc/tablet-support.dox
@@ -349,13 +349,13 @@ The exact behavior is device-dependent.
To handle a tablet correctly, libinput requires a set of capabilities
on the device. When these capabilities are missing, libinput ignores the
device and prints an error to the log. This error messages reads
-
+@verbatim
missing tablet capabilities: xy pen btn-stylus resolution. Ignoring this device.
-
+@endverbatim
or in older versions of libinput simply:
-
+@verbatim
libinput bug: device does not meet tablet criteria. Ignoring this device.
-
+@endverbatim
When a tablet is rejected, it is usually possible to check the issue with
the `evemu-descibe` tool.
diff --git a/doc/timestamps.dox b/doc/timestamps.dox
index a823c002..005777ca 100644
--- a/doc/timestamps.dox
+++ b/doc/timestamps.dox
@@ -15,14 +15,14 @@ use of timeouts to detect multi-finger taps and/or @ref tapndrag.
Consider the following event sequences from a touchpad and a mouse:
-
+@verbatim
Time Touchpad Mouse
---------------------------------
t1 finger down
t2 finger up
t3 movement
t4 tap timeout
-
+@endverbatim
For this event sequence, the first event to be sent to a caller is in
response to the mouse movement: an event of type @ref
diff --git a/doc/touchpad-jumping-cursors.dox b/doc/touchpad-jumping-cursors.dox
index e581eb1f..d8d7b10f 100644
--- a/doc/touchpad-jumping-cursors.dox
+++ b/doc/touchpad-jumping-cursors.dox
@@ -15,7 +15,7 @@ In most cases, this is a bug in the kernel driver and to libinput it appears
that the touch point moves from its previous position. The pointer jump can
usually be seen in the evemu-record output for the device:
-
+@verbatim
E: 249.206319 0000 0000 0000 # ------------ SYN_REPORT (0) ----------
E: 249.218008 0003 0035 3764 # EV_ABS / ABS_MT_POSITION_X 3764
E: 249.218008 0003 0036 2221 # EV_ABS / ABS_MT_POSITION_Y 2221
@@ -40,7 +40,7 @@ usually be seen in the evemu-record output for the device:
E: 249.254568 0003 003a 0027 # EV_ABS / ABS_MT_PRESSURE 27
E: 249.254568 0003 0000 1644 # EV_ABS / ABS_X 1644
E: 249.254568 0003 0018 0027 # EV_ABS / ABS_PRESSURE 27
-
+@endverbatim
In this recording, the pointer jumps from its position 3752/2216 to
1640/4681 within a single frame. On this particular touchpad, this would
diff --git a/doc/touchpad-pressure.dox b/doc/touchpad-pressure.dox
index b6fa064e..1aa6b2f7 100644
--- a/doc/touchpad-pressure.dox
+++ b/doc/touchpad-pressure.dox
@@ -61,7 +61,7 @@ statistics, including whether a touch is/was considered logically down.
Example output of the tool is below:
-
+@verbatim
$ sudo libinput measure touchpad-pressure
Ready for recording data.
Pressure range used: 8:10
@@ -75,7 +75,7 @@ Sequence 1192 pressure: min: 40 max: 78 avg: 64 median: 66 tags: down
Sequence 1193 pressure: min: 36 max: 83 avg: 70 median: 73 tags: down
Sequence 1194 pressure: min: 43 max: 76 avg: 72 median: 74 tags: down
Touchpad pressure: 47 min: 47 max: 86 tags: down
-
+@endverbatim
The example output shows five completed touch sequences and one ongoing one.
For each, the respective minimum and maximum pressure values are printed as
@@ -88,9 +88,9 @@ By default, this tool uses the @ref device-quirks for the pressure range. To
narrow down on the best values for your device, specify the 'logically down'
and 'logically up' pressure thresholds with the `--touch-thresholds`
argument:
-
+@verbatim
$ sudo libinput measure touchpad-pressure --touch-thresholds=10:8 --palm-threshold=20
-
+@endverbatim
Interact with the touchpad and check if the output of this tool matches your
expectations.
@@ -103,14 +103,14 @@ to the hardware can figure out the correct ranges.**
Once the thresholds are decided on (e.g. 10 and 8), they can be enabled with
@ref device-quirks entry similar to this:
-
+@verbatim
$> cat /etc/libinput/local-overrides.quirks
[Touchpad pressure override]
MatchUdevType=touchpad
MatchName=*SynPS/2 Synaptics TouchPad
MatchDMIModalias=dmi:*svnLENOVO:*:pvrThinkPadX230*
AttrPressureRange=10:8
-
+@endverbatim
The file name **must** be `/etc/libinput/local-overrides.quirks`. The
The first line is the section name and can be free-form. The `Match`
@@ -123,10 +123,10 @@ and product name (pn).
Once in place, run the following command to verify the quirk is valid and
works for your device:
-
+@verbatim
$ sudo libinput list-quirks /dev/input/event10
AttrPressureRange=10:8
-
+@endverbatim
Replace the event node with the one from your device. If the
`AttrPressureRange` quirk does not show up, re-run with `--verbose` and
check the output for any error messages.
@@ -156,7 +156,7 @@ statistics, including whether a touch is/was considered logically down.
Example output of the tool is below:
-
+@verbatim
$ sudo libinput measure touch-size --touch-thresholds 10:8 --palm-threshold 14
Using ELAN Touchscreen: /dev/input/event5
@@ -171,7 +171,7 @@ Sequence: major: [ 9.. 10] minor: [ 7.. 7]
Sequence: major: [ 9.. 14] minor: [ 6.. 9] down
Sequence: major: [ 11.. 11] minor: [ 9.. 9] down
Sequence: major: [ 4.. 33] minor: [ 1.. 5] down palm
-
+@endverbatim
The example output shows five completed touch sequences. For each, the
respective minimum and maximum pressure values are printed as well as some
@@ -196,14 +196,14 @@ to the hardware can figure out the correct ranges.**
Once the thresholds are decided on (e.g. 10 and 8), they can be enabled with
@ref device-quirks entry similar to this:
-
+@verbatim
$> cat /etc/libinput/local-overrides.quirks
[Touchpad touch size override]
MatchUdevType=touchpad
MatchName=*SynPS/2 Synaptics TouchPad
MatchDMIModalias=dmi:*svnLENOVO:*:pvrThinkPadX230*
AttrTouchSizeRange=10:8
-
+@endverbatim
The first line is the match line and should be adjusted for the device name
(see evemu-record's output) and for the local system, based on the
@@ -213,10 +213,10 @@ and product name (pn).
Once in place, run the following command to verify the quirk is valid and
works for your device:
-
+@verbatim
$ sudo libinput list-quirks /dev/input/event10
AttrTouchSizeRange=10:8
-
+@endverbatim
Replace the event node with the one from your device. If the
`AttrTouchSizeRange` quirk does not show up, re-run with `--verbose` and
check the output for any error messages.