mirror of
https://gitlab.freedesktop.org/libinput/libinput.git
synced 2026-03-23 12:00:43 +01:00
doc: replace <pre> with @verbatim
Be more consistent here Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This commit is contained in:
Peter Hutterer
parent
cb7b535c2f
commit
f4a253fb21
6 changed files with 38 additions and 38 deletions
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
16
doc/faqs.dox
16
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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue