From: Peter Hutterer <peter.hutterer@who-t.net>
Date: Thu, 21 Jun 2018 01:08:17 +0000 (+1000)
Subject: doc: use @verbatim, not @code for shell commands
X-Git-Tag: 1.11.901~117
X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=015d6f1535a78bf53ad3306d28a9e06a7539a8c8;p=platform%2Fupstream%2Flibinput.git

doc: use @verbatim, not @code for shell commands

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

diff --git a/doc/absolute-coordinate-ranges.dox b/doc/absolute-coordinate-ranges.dox
index 41659cf..3d46d58 100644
--- a/doc/absolute-coordinate-ranges.dox
+++ b/doc/absolute-coordinate-ranges.dox
@@ -41,7 +41,7 @@ and repeatedly move a finger around the whole outside area of the
 touchpad. Then control+c the process and note the output.
 An example output is below:
 
-@code
+@verbatim
 $> sudo touchpad-edge-detector /dev/input/event4
 Touchpad SynPS/2 Synaptics TouchPad on /dev/input/event4
 Move one finger around the touchpad to detect the actual edges
@@ -61,7 +61,7 @@ evdev:name:SynPS/2 Synaptics TouchPad:dmi:bvnLENOVO:bvrGJET72WW(2.22):bd02/21/20
  EVDEV_ABS_35=2445:4252:<x resolution>
  EVDEV_ABS_36=3464:4071:<y resolution>
 
-@endcode
+@endverbatim
 
 Note the discrepancy between the coordinate range the kernels advertises vs.
 what the touchpad sends.
@@ -72,23 +72,23 @@ An example commit can be found
 
 In most cases the match can and should be trimmed to the system vendor (svn)
 and the product version (pvr), with everything else replaced by a wildcard
-(*). In this case, a Lenovo T440s, a suitable match string would be: @code
+(*). In this case, a Lenovo T440s, a suitable match string would be: @verbatim
 evdev:name:SynPS/2 Synaptics TouchPad:dmi:*svnLENOVO:*pvrThinkPadT440s*
-@endcode
+@endverbatim
 
 @note hwdb match strings only allow for alphanumeric ascii characters. Use a
 wildcard (* or ?, whichever appropriate) for special characters.
 
 The actual axis overrides are in the form:
-@code
+@verbatim
 # axis number=min:max:resolution
  EVDEV_ABS_00=2445:4252:42
-@endcode
+@endverbatim
 or, if the range is correct but the resolution is wrong
-@code
+@verbatim
 # axis number=::resolution
  EVDEV_ABS_00=::42
-@endcode
+@endverbatim
 
 Note the leading single space. The axis numbers are in hex and can be found
 in *linux/input-event-codes.h*. For touchpads ABS_X, ABS_Y,
@@ -105,9 +105,9 @@ file to save it locally and trigger the udev hwdb reload. Rebooting is
 always a good idea. If the match string is correct, the new properties will
 show up in the
 output of
-@code
+@verbatim
    udevadm info /sys/class/input/event4
-@endcode
+@endverbatim
 
 Adjust the command for the event node of your touchpad.
 A udev builtin will apply the new axis ranges automatically.
diff --git a/doc/building.dox b/doc/building.dox
index 89c6016..5698fd4 100644
--- a/doc/building.dox
+++ b/doc/building.dox
@@ -17,44 +17,44 @@ libinput uses [meson](https://www.mesonbuild.com) and
 process below.  A successful build requires the @ref
 building_dependencies to be installed before running meson.
 
-@code
+@verbatim
 $> git clone https://gitlab.freedesktop.org/libinput/libinput
 $> cd libinput
 $> meson --prefix=/usr builddir/
 $> ninja -C builddir/
 $> sudo ninja -C builddir/ install
-@endcode
+@endverbatim
 
 When running libinput versions 1.11.x or earlier, you must run
-@code
+@verbatim
 $> sudo udevadm hwdb --update
-@endcode
+@endverbatim
 
 Additional options may also be specified. For example:
-@code
+@verbatim
 $> meson --prefix=/usr -Ddocumentation=false builddir/
-@endcode
+@endverbatim
 
 We recommend that users disable the documentation, it's not usually required
 for testing and reduces the number of dependencies needed.
 
 The ```prefix``` or other options can be changed later with the
 ```mesonconf``` command. For example:
-@code
+@verbatim
 $> mesonconf builddir/ -Dprefix=/some/other/prefix -Ddocumentation=true
 $> ninja -C builddir
 $> sudo ninja -C builddir/ install
-@endcode
+@endverbatim
 
 Running ``mesonconf builddir/`` with no other arguments lists all
 configurable options meson provides.
 
 To rebuild from scratch, simply remove the build directory and run meson
 again:
-@code
+@verbatim
 $> rm -r builddir/
 $> meson --prefix=....
-@endcode
+@endverbatim
 
 @subsection verifying_install Verifying the install
 
@@ -76,11 +76,11 @@ files in the system (e.g. ```/usr/lib/libinput.la```) but these files are
 usually harmless. To definitely remove all files, run the following command
 from the libinput source directory:
 
-@code
+@verbatim
 $> sudo ninja -C builddir/ uninstall
 # WARNING: Do not restart the computer/X/the Wayland compositor after
 # uninstall, reinstall the system package immediately!
-@endcode
+@endverbatim
 
 The following commands reinstall the current system package for libinput,
 overwriting manually installed files.
@@ -112,9 +112,9 @@ context ```unconfined_u:object_r:user_home_t```.
 
 To avoid this issue, restore the SELinux context for any system files.
 
-<pre>
+@verbatim
 $> sudo restorecon /usr/lib*/libinput.so.*
-</pre>
+@endverbatim
 
 This issue is tracked in https://github.com/mesonbuild/meson/issues/1967.
 
@@ -170,9 +170,9 @@ information about tablets that is not available from the kernel device
 itself. libwacom is required by default but can be skipped when @ref
 building.
 
-@code
+@verbatim
 $> meson --prefix=/usr -Dlibwacom=false builddir
-@endcode
+@endverbatim
 
 It is not recommended to disable libwacom unless libinput is used in an
 environment where tablet support is not required. libinput provides tablet
@@ -188,9 +188,9 @@ feature of the `libinput` tool is enabled and if the required libraries are
 not available, the build will fail. If the feature is not required, use the
 ``--disable-debug-gui`` argument when @ref building.
 
-@code
+@verbatim
 $> meson --prefix=/usr -Ddebug-gui=false builddir
-@endcode
+@endverbatim
 
 @subsection building_autotools Building with autotools
 
@@ -201,38 +201,38 @@ A build with automake is usually the process below. A successful build
 requires the @ref building_dependencies to be installed at configure
 time.
 
-@code
+@verbatim
 $> git clone https://gitlab.freedesktop.org/libinput/libinput
 $> cd libinput
 $> ./autogen.sh --prefix=/usr --libdir=/usr/lib64
 $> make
 $> sudo make install
 $> sudo udevadm hwdb --update
-@endcode
+@endverbatim
 
 @note On Debian-based distributions including Ubuntu and its derivatives skip the
 ```--libdir=/usr/lib64``` argument.
 
 To uninstall libinput as detailed in section @ref reverting_install, run
 
-@code
+@verbatim
 $> sudo make uninstall
 # WARNING: Do not restart the computer/X/the Wayland compositor after make
 # uninstall, reinstall the system package immediately!
-@endcode
+@endverbatim
 
 To disable libwacom as detailed in section @ref building_libwacom, run
 
-@code
+@verbatim
 $> ./autogen.sh --disable-libwacom --prefix=/usr --libdir=/usr/lib64
-@endcode
+@endverbatim
 
 To disable the graphical helper tool as detailed in section @ref
 building_debug_gui, run
 
-@code
+@verbatim
 $> ./autogen.sh --disable-debug-gui --prefix=/usr --libdir=/usr/lib64
-@endcode
+@endverbatim
 
 
 @section building_against Building against libinput
@@ -244,9 +244,9 @@ Software that uses libinput should use pkg-config and the
 Otherwise, the most rudimentary way to compile and link a program against
 libinput is:
 
-@code
+@verbatim
     gcc -o myprogram myprogram.c `pkg-config --cflags --libs libinput`
-@endcode
+@endverbatim
 
 For further information on using pkgconfig see the pkg-config documentation.
 
diff --git a/doc/reporting-bugs.dox b/doc/reporting-bugs.dox
index df1c4b4..3f4abdc 100644
--- a/doc/reporting-bugs.dox
+++ b/doc/reporting-bugs.dox
@@ -157,7 +157,7 @@ verify whether device-specific quirks were applied. This can be obtained
 with ````udevadm info /sys/class/input/eventX```, with the correct event
 node for your device. An example output is below:
 
-@code
+@verbatim
 $ udevadm info /sys/class/input/event4
 P: /devices/platform/i8042/serio1/input/input5/event4
 N: input/event4
@@ -175,7 +175,7 @@ E: MAJOR=13
 E: MINOR=68
 E: SUBSYSTEM=input
 E: USEC_INITIALIZED=5463031
-@endcode
+@endverbatim
 
 @section evemu Recording devices with evemu
 
@@ -189,7 +189,7 @@ and re-play the event sequence, hopefully triggering the same bug.
 
 evemu-record takes a <tt>/dev/input/eventX</tt> event node, but without arguments
 it will simply show the list of devices and let you select:
-@code
+@verbatim
 $ sudo evemu-record > scroll.evemu
 Available devices:
 /dev/input/event0:	Lid Switch
@@ -210,7 +210,7 @@ Available devices:
 /dev/input/event18:	Integrated Camera
 /dev/input/event19:	TPPS/2 IBM TrackPoint
 Select the device event number [0-19]:
-@endcode
+@endverbatim
 
 Select the device that triggers the issue, then reproduce the bug and Ctrl+C
 the process. The resulting recording, ("scroll.evemu" in this example) will
@@ -225,9 +225,9 @@ sequence triggering the bug. Please keep the event sequence as short as possible
 
 To verify that the recording contains the bug, you can replay it on your
 device. For example, to replay the sequence recorded in the example above:
-@code
+@verbatim
 $ sudo evemu-play /dev/input/event4 < scroll.evemu
-@endcode
+@endverbatim
 
 If the bug is triggered by replaying on your device, attach the recording to
 the bug report.
diff --git a/doc/test-suite.dox b/doc/test-suite.dox
index d939689..a7a55a2 100644
--- a/doc/test-suite.dox
+++ b/doc/test-suite.dox
@@ -44,7 +44,7 @@ devices. The `--list` commandline argument shows the list of suites and
 tests. This is useful when trying to figure out if a specific test is
 run for a device.
 
-@code
+@verbatim
 $ ./test/libinput-test-suite-runner --list
 ...
 pointer:left-handed:
@@ -82,7 +82,7 @@ pointer:left-handed:
 		mouse-wheel-tilt
 		mouse
 ...
-@endcode
+@endverbatim
 
 In the above example, the "pointer:left-handed" suite contains multiple
 tests, e.g. "pointer_left_handed_during_click" (this is also the function
@@ -97,25 +97,25 @@ instantiate one).
 The `--filter-test` argument enables selective running of tests through
 basic shell-style function name matching. For example:
 
-@code
+@verbatim
 $ ./test/libinput-test-suite-runner --filter-test="*1fg_tap*"
-@endcode
+@endverbatim
 
 The `--filter-device` argument enables selective running of tests through
 basic shell-style device name matching. The device names matched are the
 litest-specific shortnames, see the output of `--list`. For example:
 
-@code
+@verbatim
 $ ./test/libinput-test-suite-runner --filter-device="synaptics*"
-@endcode
+@endverbatim
 
 The `--filter-group` argument enables selective running of test groups
 through basic shell-style test group matching. The test groups matched are
 litest-specific test groups, see the output of `--list`. For example:
 
-@code
+@verbatim
 $ ./test/libinput-test-suite-runner --filter-group="touchpad:*hover*"
-@endcode
+@endverbatim
 
 The `--filter-device` and `--filter-group` arguments can be combined with
 `--list` to show which groups and devices will be affected.
@@ -126,9 +126,9 @@ Each test supports the `--verbose` commandline option to enable debugging
 output, see libinput_log_set_priority() for details. The `LITEST_VERBOSE`
 environment variable, if set, also enables verbose mode.
 
-@code
+@verbatim
 $ ./test/libinput-test-suite-runner --verbose
 $ LITEST_VERBOSE=1 ninja test
-@endcode
+@endverbatim
 
 */
diff --git a/doc/trackpoints.dox b/doc/trackpoints.dox
index ab0876f..5cdc64d 100644
--- a/doc/trackpoints.dox
+++ b/doc/trackpoints.dox
@@ -44,7 +44,7 @@ device-quirks to make this range known to libinput. libinput provides the tool
 tool and prints its instructions on the commandline. Example output from
 this tool is below:
 
-@code
+@verbatim
 $ sudo libinput measure trackpoint-range
 This tool measures the commonly used pressure range of the
 trackpoint. Push the trackpoint:
@@ -59,14 +59,14 @@ during day-to-day movement. For best results, run this tool
 several times to get an idea of the common range.
 
 Trackpoint sends: max x: 19, max y: 23 samples [121, 121]
-@endcode
+@endverbatim
 
 Once sufficient samples have been collected, the tool prints a simplified
 histogram for x and y axis deltas. This histogram should be used to
 <b>estimate</b> the appropriate trackpoint range. For example, let's look at
 the histogram below:
 
-@code
+@verbatim
 Histogram for x axis deltas, in counts of 5
  -30:
  -29:
@@ -133,7 +133,7 @@ Histogram for x axis deltas, in counts of 5
   32:
   33:
   34:
-@endcode
+@endverbatim
 
 The 0 delta is the neutral state, each + represents 5 events with that
 delta value. Note how the curve is distributed, it's not a classic bell