[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Git][xorg-team/lib/libinput][upstream-unstable] 10 commits: doc: add the switches page to a "other devices" category



Title: GitLab

Timo Aaltonen pushed to branch upstream-unstable at X Strike Force / lib / libinput

Commits:

9 changed files:

Changes:

  • README.md
    ... ... @@ -11,6 +11,17 @@ provide the common set of functionality that users expect. Input event
    11 11
     processing includes scaling touch coordinates, generating
    
    12 12
     relative pointer events from touchpads, pointer acceleration, etc.
    
    13 13
     
    
    14
    +User documentation
    
    15
    +------------------
    
    16
    +
    
    17
    +Documentation explaining features available in libinput is available
    
    18
    +[here](https://wayland.freedesktop.org/libinput/doc/latest/pages.html).
    
    19
    +
    
    20
    +This includes the [FAQ](https://wayland.freedesktop.org/libinput/doc/latest/faq.html)
    
    21
    +and the instructions on
    
    22
    +[reporting bugs](https://wayland.freedesktop.org/libinput/doc/latest/reporting_bugs.html).
    
    23
    +
    
    24
    +
    
    14 25
     Architecture
    
    15 26
     ------------
    
    16 27
     
    

  • doc/faqs.dox
    ... ... @@ -220,4 +220,27 @@ The warning has no immediate effect on libinput's behavior but some of the
    220 220
     functionality that relies on the timer may be impeded (e.g. palms are not
    
    221 221
     detected as they should be).
    
    222 222
     
    
    223
    +@section faq_wayland Is libinput required for Wayland?
    
    224
    +
    
    225
    +Technically - no. But for your use-case - probably.
    
    226
    +
    
    227
    +Wayland is a display server communication protocol. libinput is a low-level
    
    228
    +library to simplify handling input devices and their events. They have no
    
    229
    +direct connection. As a technical analogy, the question is similar to "is
    
    230
    +glibc required for HTTP", or (stretching the analogy a bit further) "Is a
    
    231
    +pen required to write English". No, it isn't.
    
    232
    +
    
    233
    +You can use libinput without a Wayland compositor, you can
    
    234
    +write a Wayland compositor without libinput. Until 2018 the most common use
    
    235
    +of libinput is with the X.Org X server through the xf86-input-libinput
    
    236
    +driver. As Wayland compositors become more commonplace they will eventually
    
    237
    +overtake X.
    
    238
    +
    
    239
    +So why "for your use-case - probably"?  All general-purpose Wayland
    
    240
    +compositors use libinput for their input stack.  Wayland compositors that
    
    241
    +are more specialized (e.g. in-vehicle infotainment or IVI) can handle input
    
    242
    +devices directly but the compositor you want to use
    
    243
    +on your desktop needs an input stack that is more complex. And right now,
    
    244
    +libinput is the only input stack that exists for this use-case.
    
    245
    +
    
    223 246
     */

  • doc/page-hierarchy.dox
    ... ... @@ -35,6 +35,10 @@
    35 35
     
    
    36 36
     - @subpage tablet-support
    
    37 37
     
    
    38
    +@page other_devices Other devices
    
    39
    +
    
    40
    +- @subpage switches
    
    41
    +
    
    38 42
     @page general General 
    
    39 43
     
    
    40 44
     - @subpage udev_config
    

  • doc/switches.dox
    1 1
     /**
    
    2 2
     @page switches Switches
    
    3 3
     
    
    4
    -libinput supports a couple of switches. Unlike button events that come in
    
    5
    -press and release pairs, switches are usually toggled once and left at the
    
    6
    -setting for an extended period of time.
    
    4
    +libinput supports the lid and tablet-mode switches. Unlike button events
    
    5
    +that come in press and release pairs, switches are usually toggled once and
    
    6
    +left at the setting for an extended period of time.
    
    7 7
     
    
    8 8
     Only some switches are handled by libinput, see @ref libinput_switch for a
    
    9 9
     list of supported switches. Switch events are exposed to the caller, but
    

  • doc/tools.dox
    ... ... @@ -202,6 +202,35 @@ have captured the bug.
    202 202
     More arguments are available, see the **libinput-record(1)** and
    
    203 203
     **libinput-replay(1)** man pages.
    
    204 204
     
    
    205
    +@subsection libinput-record-autorestart libinput record's autorestart feature
    
    206
    +
    
    207
    +`libinput record` often collects thousands of events per minute. However,
    
    208
    +the output of `libinput record` usually needs to be visually inspected
    
    209
    +or replayed in realtime on a developer machine. It is thus imperative that
    
    210
    +the event log is kept as short as possible.
    
    211
    +
    
    212
    +For bugs that are difficult to reproduce use
    
    213
    +`libinput record --autorestart=2 --output-file=recording.yml`.
    
    214
    +All events will be recorded to a file named
    
    215
    +`recording.yml.<current-date-and-time>` and whenever the device does not
    
    216
    +send events for 2 seconds, a new file is created. This helps to keep
    
    217
    +individual recordings short.
    
    218
    +
    
    219
    +To use the `--autorestart` option correctly:
    
    220
    +- run `libinput record --autorestart=2 --output-file=<somefilename>.yml`.
    
    221
    +  You may provide a timeout other than 2 if needed.
    
    222
    +- use the device to reproduce the bug, pausing frequently for 2s and longer
    
    223
    +  to rotate the logs
    
    224
    +- when the bug triggers, **immediately stop using the device** and wait
    
    225
    +  several seconds for the log to rotate
    
    226
    +- Ctrl+C the `libinput record` process without using the device
    
    227
    +  again. Attach the **last recording** to the bug report.
    
    228
    +
    
    229
    +If you have to use the recorded device to stop `libinput record` (e.g. to
    
    230
    +switch windows), remember that this will cause a new recording to be
    
    231
    +created. Thus, attach the **second-to-last recording** to the bug report
    
    232
    +because this one contains the bug trigger.
    
    233
    +
    
    205 234
     @subsection libinput-record-multiple Recording multiple devices at once
    
    206 235
     
    
    207 236
     In some cases, an interaction between multiple devices is the cause for a
    
    ... ... @@ -226,7 +255,7 @@ Replaying events is the same as for a single recording:
    226 255
     $ sudo libinput replay touchpad-bug.log
    
    227 256
     @endverbatim
    
    228 257
     
    
    229
    -@subsection libinput-measure Measuring device properties with libinput measure
    
    258
    +@section libinput-measure Measuring device properties with libinput measure
    
    230 259
     
    
    231 260
     The `libinput measure` tool is a multiplexer for various sub-tools that can
    
    232 261
     measure specific properties on the device. These tools generally measure one
    

  • meson.build
    1 1
     project('libinput', 'c', 'cpp',
    
    2
    -	version : '1.11.2',
    
    2
    +	version : '1.11.3',
    
    3 3
     	license : 'MIT/Expat',
    
    4 4
     	default_options : [ 'c_std=gnu99', 'warning_level=2' ],
    
    5 5
     	meson_version : '>= 0.40.0')
    

  • tools/libinput-replay
    ... ... @@ -89,6 +89,10 @@ def create(device):
    89 89
                         data = 20
    
    90 90
                 d.enable(libevdev.evbit(evtype, code), data=data)
    
    91 91
     
    
    92
    +    properties = fetch(evdev, 'properties')
    
    93
    +    for prop in properties:
    
    94
    +        d.enable(libevdev.propbit(prop))
    
    95
    +
    
    92 96
         uinput = d.create_uinput_device()
    
    93 97
         return uinput
    
    94 98
     
    

  • tools/shared.c
    ... ... @@ -267,10 +267,9 @@ tools_open_udev(const char *seat, bool verbose, bool *grab)
    267 267
     		goto out;
    
    268 268
     	}
    
    269 269
     
    
    270
    -	if (verbose) {
    
    271
    -		libinput_log_set_handler(li, log_handler);
    
    270
    +	libinput_log_set_handler(li, log_handler);
    
    271
    +	if (verbose)
    
    272 272
     		libinput_log_set_priority(li, LIBINPUT_LOG_PRIORITY_DEBUG);
    
    273
    -	}
    
    274 273
     
    
    275 274
     	if (libinput_udev_assign_seat(li, seat)) {
    
    276 275
     		fprintf(stderr, "Failed to set seat\n");
    

  • udev/90-libinput-model-quirks.hwdb
    ... ... @@ -175,6 +175,10 @@ libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*
    175 175
     # HP
    
    176 176
     ##########################################
    
    177 177
     
    
    178
    +# HP Chromebook 14
    
    179
    +libinput:name:*Cypress APA Trackpad *cyapa*:dmi:*svnHewlett-Packard*:pnFalco*
    
    180
    + LIBINPUT_ATTR_PRESSURE_RANGE=12:8
    
    181
    +
    
    178 182
     # HP Compaq6910p
    
    179 183
     libinput:name:SynPS/2 Synaptics TouchPad:dmi:*svnHewlett-Packard:*pnHPCompaq6910p*
    
    180 184
      LIBINPUT_MODEL_HP6910_TOUCHPAD=1
    


  • Reply to: