doc: replace <pre> with @verbatim

Be more consistent here

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

diff --git a/doc/building.dox b/doc/building.dox
index 5698fd46c1a843aeaa868d323be8c2aa036b62e4..726a3db9acf797dfd04252353ff80e71edc3b09e 100644 (file)
--- 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.
-<pre>
+@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
-</pre>
+@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:
 
-<pre>
+@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
-</pre>
+@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```</li>
 <li><b>Fedora 22</b> and later: ```sudo dnf builddep libinput```</li>
 <li><b>RHEL/CentOS/Fedora 21</b> and earlier: ```sudo yum-builddep libinput```</li>
 <li><b>openSUSE</b>:
-<pre>
+@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}'`
-</pre>
+@endverbatim
 </li>
 <li><b>Arch</b>:
-<pre>
+@verbatim
 $> sudo pacman -S asp
 $> cd $(mktemp -d)
 $> asp export libinput
 $> cd libinput
 $> makepkg --syncdeps --nobuild --noextract
-</pre>
+@endverbatim
 </li>
 </ul>
 

diff --git a/doc/faqs.dox b/doc/faqs.dox
index b9c12df39c97a69d27d2103c6bb70a4df10b0fd4..6d0c29775812e3f78e6a5234aa834d4a81e1c6ad 100644 (file)
--- 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
 <a href="https://www.x.org/archive/current/doc/man/man5/xorg.conf.5.xhtml">xorg.conf.d snippet</a>.
 Usually, such a snippet looks like this:
-<pre>
+@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
-</pre>
+@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
 <a href="https://www.mankier.com/4/libinput">libinput man page</a>
 for supported property names and values. Usually, an invocation looks like
 this:
-<pre>
+@verbatim
 $> xinput set-prop "the device name" "the property name" value [value2] [value3]
-</pre>
+@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
-<pre>
+@verbatim
 libinput bug: device does not meet tablet criteria. Ignoring this device.
-</pre>
+@endverbatim
 
 or the message
-<pre>
+@verbatim
 missing tablet capabilities [...] Ignoring this device.
-</pre>
+@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 054ef57027c5366cde8828e3352e248c93f77e95..bd08baf6cdb1dd334437e81f67bd51848aaff344 100644 (file)
--- 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
-<pre>
+@verbatim
 missing tablet capabilities: xy pen btn-stylus resolution. Ignoring this device.
-</pre>
+@endverbatim
 or in older versions of libinput simply:
-<pre>
+@verbatim
 libinput bug: device does not meet tablet criteria. Ignoring this device.
-</pre>
+@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 a823c00255d3eec5ea386f73990116494b8b7907..005777cac5f77eda2337e7f35c2db430b4fb327c 100644 (file)
--- 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:
 
-<pre>
+@verbatim
 Time      Touchpad      Mouse
 ---------------------------------
 t1       finger down
 t2        finger up
 t3                     movement
 t4       tap timeout
-</pre>
+@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 e581eb1f257cd149730d75e6457e1dee731870b8..d8d7b10fc882a36d6de641f25d4d97dc08943e32 100644 (file)
--- 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:
 
-<pre>
+@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
-</pre>
+@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 b6fa064e3c138ea507133f29d7f9bdacb510c8d0..1aa6b2f7878813bfb19abbc7d9333e3d5e910c1f 100644 (file)
--- 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:
 
-<pre>
+@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
-</pre>
+@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:
-<pre>
+@verbatim
 $ sudo libinput measure touchpad-pressure --touch-thresholds=10:8 --palm-threshold=20
-</pre>
+@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:
 
-<pre>
+@verbatim
 $> cat /etc/libinput/local-overrides.quirks
 [Touchpad pressure override]
 MatchUdevType=touchpad
 MatchName=*SynPS/2 Synaptics TouchPad
 MatchDMIModalias=dmi:*svnLENOVO:*:pvrThinkPadX230*
 AttrPressureRange=10:8
-</pre>
+@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:
-<pre>
+@verbatim
 $ sudo libinput list-quirks /dev/input/event10
 AttrPressureRange=10:8
-</pre>
+@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:
 
-<pre>
+@verbatim
 $ sudo libinput measure touch-size --touch-thresholds 10:8 --palm-threshold 14
 Using ELAN Touchscreen: /dev/input/event5
 &nbsp;
@@ -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
-</pre>
+@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:
 
-<pre>
+@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
-</pre>
+@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:
-<pre>
+@verbatim
 $ sudo libinput list-quirks /dev/input/event10
 AttrTouchSizeRange=10:8
-</pre>
+@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.