1 .. SPDX-License-Identifier: GPL-2.0
2
3 ======================================
4 Introduction to HID report descriptors
5 ======================================
6
7 This chapter is meant to give a broad overview of what HID report
8 descriptors are, and of how a casual (non-kernel) programmer can deal
9 with HID devices that are not working well with Linux.
10
11 .. contents::
12 :local:
13 :depth: 2
14
15 .. toctree::
16 :maxdepth: 2
17
18 hidreport-parsing
19
20
21 Introduction
22 ============
23
24 HID stands for Human Interface Device, and can be whatever device you
25 are using to interact with a computer, be it a mouse, a touchpad, a
26 tablet, a microphone.
27
28 Many HID devices work out the box, even if their hardware is different.
29 For example, mice can have any number of buttons; they may have a
30 wheel; movement sensitivity differs between different models, and so
31 on. Nonetheless, most of the time everything just works, without the
32 need to have specialized code in the kernel for every mouse model
33 developed since 1970.
34
35 This is because modern HID devices do advertise their capabilities
36 through the *HID report descriptor*, a fixed set of bytes describing
37 exactly what *HID reports* may be sent between the device and the host
38 and the meaning of each individual bit in those reports. For example,
39 a HID Report Descriptor may specify that "in a report with ID 3 the
40 bits from 8 to 15 is the delta x coordinate of a mouse".
41
42 The HID report itself then merely carries the actual data values
43 without any extra meta information. Note that HID reports may be sent
44 from the device ("Input Reports", i.e. input events), to the device
45 ("Output Reports" to e.g. change LEDs) or used for device configuration
46 ("Feature reports"). A device may support one or more HID reports.
47
48 The HID subsystem is in charge of parsing the HID report descriptors,
49 and converts HID events into normal input device interfaces (see
50 Documentation/hid/hid-transport.rst). Devices may misbehave because the
51 HID report descriptor provided by the device is wrong, or because it
52 needs to be dealt with in a special way, or because some special
53 device or interaction mode is not handled by the default code.
54
55 The format of HID report descriptors is described by two documents,
56 available from the `USB Implementers Forum <https://www.usb.org/>`_
57 `HID web page <https://www.usb.org/hid>`_ address:
58
59 * the `HID USB Device Class Definition
60 <https://www.usb.org/document-library/device-class-definition-hid-111>`_ (HID Spec from now on)
61 * the `HID Usage Tables <https://usb.org/document-library/hid-usage-tables-14>`_ (HUT from now on)
62
63 The HID subsystem can deal with different transport drivers
64 (USB, I2C, Bluetooth, etc.). See Documentation/hid/hid-transport.rst.
65
66 Parsing HID report descriptors
67 ==============================
68
69 The current list of HID devices can be found at ``/sys/bus/hid/devices/``.
70 For each device, say ``/sys/bus/hid/devices/0003\:093A\:2510.0002/``,
71 one can read the corresponding report descriptor::
72
73 $ hexdump -C /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
74 00000000 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 |..............).|
75 00000010 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 |..%.u.....u.....|
76 00000020 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 |...0.1.8..%.u...|
77 00000030 81 06 c0 c0 |....|
78 00000034
79
80 Optional: the HID report descriptor can be read also by
81 directly accessing the hidraw driver [#hidraw]_.
82
83 The basic structure of HID report descriptors is defined in the HID
84 spec, while HUT "defines constants that can be interpreted by an
85 application to identify the purpose and meaning of a data field in a
86 HID report". Each entry is defined by at least two bytes, where the
87 first one defines what type of value is following and is described in
88 the HID spec, while the second one carries the actual value and is
89 described in the HUT.
90
91 HID report descriptors can, in principle, be painstakingly parsed by
92 hand, byte by byte.
93
94 A short introduction on how to do this is sketched in
95 Documentation/hid/hidreport-parsing.rst; you only need to understand it
96 if you need to patch HID report descriptors.
97
98 In practice you should not parse HID report descriptors by hand; rather,
99 you should use an existing parser. Among all the available ones
100
101 * the online `USB Descriptor and Request Parser
102 <http://eleccelerator.com/usbdescreqparser/>`_;
103 * `hidrdd <https://github.com/abend0c1/hidrdd>`_,
104 that provides very detailed and somewhat verbose descriptions
105 (verbosity can be useful if you are not familiar with HID report
106 descriptors);
107 * `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_,
108 a complete utility set that allows, among other things,
109 to record and replay the raw HID reports and to debug
110 and replay HID devices.
111 It is being actively developed by the Linux HID subsystem maintainers.
112
113 Parsing the mouse HID report descriptor with `hid-tools
114 <https://gitlab.freedesktop.org/libevdev/hid-tools>`_ leads to
115 (explanations interposed)::
116
117 $ ./hid-decode /sys/bus/hid/devices/0003\:093A\:2510.0002/report_descriptor
118 # device 0:0
119 # 0x05, 0x01, // Usage Page (Generic Desktop) 0
120 # 0x09, 0x02, // Usage (Mouse) 2
121 # 0xa1, 0x01, // Collection (Application) 4
122 # 0x09, 0x01, // Usage (Pointer) 6
123 # 0xa1, 0x00, // Collection (Physical) 8
124 # 0x05, 0x09, // Usage Page (Button) 10
125
126 what follows is a button ::
127
128 # 0x19, 0x01, // Usage Minimum (1) 12
129 # 0x29, 0x03, // Usage Maximum (3) 14
130
131 first button is button number 1, last button is button number 3 ::
132
133 # 0x15, 0x00, // Logical Minimum (0) 16
134 # 0x25, 0x01, // Logical Maximum (1) 18
135
136 each button can send values from 0 up to including 1
137 (i.e. they are binary buttons) ::
138
139 # 0x75, 0x01, // Report Size (1) 20
140
141 each button is sent as exactly one bit ::
142
143 # 0x95, 0x03, // Report Count (3) 22
144
145 and there are three of those bits (matching the three buttons) ::
146
147 # 0x81, 0x02, // Input (Data,Var,Abs) 24
148
149 it's actual Data (not constant padding), they represent
150 a single variable (Var) and their values are Absolute (not relative);
151 See HID spec Sec. 6.2.2.5 "Input, Output, and Feature Items" ::
152
153 # 0x75, 0x05, // Report Size (5) 26
154
155 five additional padding bits, needed to reach a byte ::
156
157 # 0x95, 0x01, // Report Count (1) 28
158
159 those five bits are repeated only once ::
160
161 # 0x81, 0x01, // Input (Cnst,Arr,Abs) 30
162
163 and take Constant (Cnst) values i.e. they can be ignored. ::
164
165 # 0x05, 0x01, // Usage Page (Generic Desktop) 32
166 # 0x09, 0x30, // Usage (X) 34
167 # 0x09, 0x31, // Usage (Y) 36
168 # 0x09, 0x38, // Usage (Wheel) 38
169
170 The mouse has also two physical positions (Usage (X), Usage (Y))
171 and a wheel (Usage (Wheel)) ::
172
173 # 0x15, 0x81, // Logical Minimum (-127) 40
174 # 0x25, 0x7f, // Logical Maximum (127) 42
175
176 each of them can send values ranging from -127 up to including 127 ::
177
178 # 0x75, 0x08, // Report Size (8) 44
179
180 which is represented by eight bits ::
181
182 # 0x95, 0x03, // Report Count (3) 46
183
184 and there are three of those eight bits, matching X, Y and Wheel. ::
185
186 # 0x81, 0x06, // Input (Data,Var,Rel) 48
187
188 This time the data values are Relative (Rel), i.e. they represent
189 the change from the previously sent report (event) ::
190
191 # 0xc0, // End Collection 50
192 # 0xc0, // End Collection 51
193 #
194 R: 52 05 01 09 02 a1 01 09 01 a1 00 05 09 19 01 29 03 15 00 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 c0 c0
195 N: device 0:0
196 I: 3 0001 0001
197
198
199 This Report Descriptor tells us that the mouse input will be
200 transmitted using four bytes: the first one for the buttons (three
201 bits used, five for padding), the last three for the mouse X, Y and
202 wheel changes, respectively.
203
204 Indeed, for any event, the mouse will send a *report* of four bytes.
205 We can check the values sent by resorting e.g. to the `hid-recorder`
206 tool, from `hid-tools <https://gitlab.freedesktop.org/libevdev/hid-tools>`_:
207 The sequence of bytes sent by clicking and releasing button 1, then button 2, then button 3 is::
208
209 $ sudo ./hid-recorder /dev/hidraw1
210
211 ....
212 output of hid-decode
213 ....
214
215 # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
216 E: 000000.000000 4 01 00 00 00
217 # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
218 E: 000000.183949 4 00 00 00 00
219 # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
220 E: 000001.959698 4 02 00 00 00
221 # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
222 E: 000002.103899 4 00 00 00 00
223 # Button: 0 0 1 | # | X: 0 | Y: 0 | Wheel: 0
224 E: 000004.855799 4 04 00 00 00
225 # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
226 E: 000005.103864 4 00 00 00 00
227
228 This example shows that when button 2 is clicked,
229 the bytes ``02 00 00 00`` are sent, and the immediately subsequent
230 event (``00 00 00 00``) is the release of button 2 (no buttons are
231 pressed, remember that the data values are *absolute*).
232
233 If instead one clicks and holds button 1, then clicks and holds button
234 2, releases button 1, and finally releases button 2, the reports are::
235
236 # Button: 1 0 0 | # | X: 0 | Y: 0 | Wheel: 0
237 E: 000044.175830 4 01 00 00 00
238 # Button: 1 1 0 | # | X: 0 | Y: 0 | Wheel: 0
239 E: 000045.975997 4 03 00 00 00
240 # Button: 0 1 0 | # | X: 0 | Y: 0 | Wheel: 0
241 E: 000047.407930 4 02 00 00 00
242 # Button: 0 0 0 | # | X: 0 | Y: 0 | Wheel: 0
243 E: 000049.199919 4 00 00 00 00
244
245 where with ``03 00 00 00`` both buttons are pressed, and with the
246 subsequent ``02 00 00 00`` button 1 is released while button 2 is still
247 active.
248
249 Output, Input and Feature Reports
250 ---------------------------------
251
252 HID devices can have Input Reports, like in the mouse example, Output
253 Reports, and Feature Reports. "Output" means that the information is
254 sent to the device. For example, a joystick with force feedback will
255 have some output; the led of a keyboard would need an output as well.
256 "Input" means that data come from the device.
257
258 "Feature"s are not meant to be consumed by the end user and define
259 configuration options for the device. They can be queried from the host;
260 when declared as *Volatile* they should be changed by the host.
261
262
263 Collections, Report IDs and Evdev events
264 ========================================
265
266 A single device can logically group data into different independent
267 sets, called a *Collection*. Collections can be nested and there are
268 different types of collections (see the HID spec 6.2.2.6
269 "Collection, End Collection Items" for details).
270
271 Different reports are identified by means of different *Report ID*
272 fields, i.e. a number identifying the structure of the immediately
273 following report.
274 Whenever a Report ID is needed it is transmitted as the first byte of
275 any report. A device with only one supported HID report (like the mouse
276 example above) may omit the report ID.
277
278 Consider the following HID report descriptor::
279
280 05 01 09 02 A1 01 85 01 05 09 19 01 29 05 15 00
281 25 01 95 05 75 01 81 02 95 01 75 03 81 01 05 01
282 09 30 09 31 16 00 F8 26 FF 07 75 0C 95 02 81 06
283 09 38 15 80 25 7F 75 08 95 01 81 06 05 0C 0A 38
284 02 15 80 25 7F 75 08 95 01 81 06 C0 05 01 09 02
285 A1 01 85 02 05 09 19 01 29 05 15 00 25 01 95 05
286 75 01 81 02 95 01 75 03 81 01 05 01 09 30 09 31
287 16 00 F8 26 FF 07 75 0C 95 02 81 06 09 38 15 80
288 25 7F 75 08 95 01 81 06 05 0C 0A 38 02 15 80 25
289 7F 75 08 95 01 81 06 C0 05 01 09 07 A1 01 85 05
290 05 07 15 00 25 01 09 29 09 3E 09 4B 09 4E 09 E3
291 09 E8 09 E8 09 E8 75 01 95 08 81 02 95 00 81 01
292 C0 05 0C 09 01 A1 01 85 06 15 00 25 01 75 01 95
293 01 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
294 06 09 3F 81 06 09 3F 81 06 09 3F 81 06 09 3F 81
295 06 C0 05 0C 09 01 A1 01 85 03 09 05 15 00 26 FF
296 00 75 08 95 02 B1 02 C0
297
298 After parsing it (try to parse it on your own using the suggested
299 tools!) one can see that the device presents two ``Mouse`` Application
300 Collections (with reports identified by Reports IDs 1 and 2,
301 respectively), a ``Keypad`` Application Collection (whose report is
302 identified by the Report ID 5) and two ``Consumer Controls`` Application
303 Collections, (with Report IDs 6 and 3, respectively). Note, however,
304 that a device can have different Report IDs for the same Application
305 Collection.
306
307 The data sent will begin with the Report ID byte, and will be followed
308 by the corresponding information. For example, the data transmitted for
309 the last consumer control::
310
311 0x05, 0x0C, // Usage Page (Consumer)
312 0x09, 0x01, // Usage (Consumer Control)
313 0xA1, 0x01, // Collection (Application)
314 0x85, 0x03, // Report ID (3)
315 0x09, 0x05, // Usage (Headphone)
316 0x15, 0x00, // Logical Minimum (0)
317 0x26, 0xFF, 0x00, // Logical Maximum (255)
318 0x75, 0x08, // Report Size (8)
319 0x95, 0x02, // Report Count (2)
320 0xB1, 0x02, // Feature (Data,Var,Abs,No Wrap,Linear,Preferred State,No Null Position,Non-volatile)
321 0xC0, // End Collection
322
323 will be of three bytes: the first for the Report ID (3), the next two
324 for the headphone, with two (``Report Count (2)``) bytes
325 (``Report Size (8)``), each ranging from 0 (``Logical Minimum (0)``)
326 to 255 (``Logical Maximum (255)``).
327
328 All the Input data sent by the device should be translated into
329 corresponding Evdev events, so that the remaining part of the stack can
330 know what is going on, e.g. the bit for the first button translates into
331 the ``EV_KEY/BTN_LEFT`` evdev event and relative X movement translates
332 into the ``EV_REL/REL_X`` evdev event".
333
334 Events
335 ======
336
337 In Linux, one ``/dev/input/event*`` is created for each ``Application
338 Collection``. Going back to the mouse example, and repeating the
339 sequence where one clicks and holds button 1, then clicks and holds
340 button 2, releases button 1, and finally releases button 2, one gets::
341
342 $ sudo libinput record /dev/input/event1
343 # libinput record
344 version: 1
345 ndevices: 1
346 libinput:
347 version: "1.23.0"
348 git: "unknown"
349 system:
350 os: "opensuse-tumbleweed:20230619"
351 kernel: "6.3.7-1-default"
352 dmi: "dmi:bvnHP:bvrU77Ver.01.05.00:bd03/24/2022:br5.0:efr20.29:svnHP:pnHPEliteBook64514inchG9NotebookPC:pvr:rvnHP:rn89D2:rvrKBCVersion14.1D.00:cvnHP:ct10:cvr:sku5Y3J1EA#ABZ:"
353 devices:
354 - node: /dev/input/event1
355 evdev:
356 # Name: PixArt HP USB Optical Mouse
357 # ID: bus 0x3 vendor 0x3f0 product 0x94a version 0x111
358 # Supported Events:
359 # Event type 0 (EV_SYN)
360 # Event type 1 (EV_KEY)
361 # Event code 272 (BTN_LEFT)
362 # Event code 273 (BTN_RIGHT)
363 # Event code 274 (BTN_MIDDLE)
364 # Event type 2 (EV_REL)
365 # Event code 0 (REL_X)
366 # Event code 1 (REL_Y)
367 # Event code 8 (REL_WHEEL)
368 # Event code 11 (REL_WHEEL_HI_RES)
369 # Event type 4 (EV_MSC)
370 # Event code 4 (MSC_SCAN)
371 # Properties:
372 name: "PixArt HP USB Optical Mouse"
373 id: [3, 1008, 2378, 273]
374 codes:
375 0: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] # EV_SYN
376 1: [272, 273, 274] # EV_KEY
377 2: [0, 1, 8, 11] # EV_REL
378 4: [4] # EV_MSC
379 properties: []
380 hid: [
381 0x05, 0x01, 0x09, 0x02, 0xa1, 0x01, 0x09, 0x01, 0xa1, 0x00, 0x05, 0x09, 0x19, 0x01, 0x29, 0x03,
382 0x15, 0x00, 0x25, 0x01, 0x95, 0x08, 0x75, 0x01, 0x81, 0x02, 0x05, 0x01, 0x09, 0x30, 0x09, 0x31,
383 0x09, 0x38, 0x15, 0x81, 0x25, 0x7f, 0x75, 0x08, 0x95, 0x03, 0x81, 0x06, 0xc0, 0xc0
384 ]
385 udev:
386 properties:
387 - ID_INPUT=1
388 - ID_INPUT_MOUSE=1
389 - LIBINPUT_DEVICE_GROUP=3/3f0/94a:usb-0000:05:00.3-2
390 quirks:
391 events:
392 # Current time is 12:31:56
393 - evdev:
394 - [ 0, 0, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
395 - [ 0, 0, 1, 272, 1] # EV_KEY / BTN_LEFT 1
396 - [ 0, 0, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +0ms
397 - evdev:
398 - [ 1, 207892, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
399 - [ 1, 207892, 1, 273, 1] # EV_KEY / BTN_RIGHT 1
400 - [ 1, 207892, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1207ms
401 - evdev:
402 - [ 2, 367823, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
403 - [ 2, 367823, 1, 272, 0] # EV_KEY / BTN_LEFT 0
404 - [ 2, 367823, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +1160ms
405 # Current time is 12:32:00
406 - evdev:
407 - [ 3, 247617, 4, 4, 30] # EV_MSC / MSC_SCAN 30 (obfuscated)
408 - [ 3, 247617, 1, 273, 0] # EV_KEY / BTN_RIGHT 0
409 - [ 3, 247617, 0, 0, 0] # ------------ SYN_REPORT (0) ---------- +880ms
410
411 Note: if ``libinput record`` is not available on your system try using
412 ``evemu-record``.
413
414 When something does not work
415 ============================
416
417 There can be a number of reasons why a device does not behave
418 correctly. For example
419
420 * The HID report descriptor provided by the HID device may be wrong
421 because e.g.
422
423 * it does not follow the standard, so that the kernel
424 will not able to make sense of the HID report descriptor;
425 * the HID report descriptor *does not match* what is actually
426 sent by the device (this can be verified by reading the raw HID
427 data);
428 * the HID report descriptor may need some "quirks" (see later on).
429
430 As a consequence, a ``/dev/input/event*`` may not be created
431 for each Application Collection, and/or the events
432 there may not match what you would expect.
433
434
435 Quirks
436 ------
437
438 There are some known peculiarities of HID devices that the kernel
439 knows how to fix - these are called the HID quirks and a list of those
440 is available in `include/linux/hid.h`.
441
442 Should this be the case, it should be enough to add the required quirk
443 in the kernel, for the HID device at hand. This can be done in the file
444 `drivers/hid/hid-quirks.c`. How to do it should be relatively
445 straightforward after looking into the file.
446
447 The list of currently defined quirks, from `include/linux/hid.h`, is
448
449 .. kernel-doc:: include/linux/hid.h
450 :doc: HID quirks
451
452 Quirks for USB devices can be specified while loading the usbhid module,
453 see ``modinfo usbhid``, although the proper fix should go into
454 hid-quirks.c and **be submitted upstream**.
455 See Documentation/process/submitting-patches.rst for guidelines on how
456 to submit a patch. Quirks for other busses need to go into hid-quirks.c.
457
458 Fixing HID report descriptors
459 -----------------------------
460
461 Should you need to patch HID report descriptors the easiest way is to
462 resort to eBPF, as described in Documentation/hid/hid-bpf.rst.
463
464 Basically, you can change any byte of the original HID report
465 descriptor. The examples in samples/hid should be a good starting point
466 for your code, see e.g. `samples/hid/hid_mouse.bpf.c`::
467
468 SEC("fmod_ret/hid_bpf_rdesc_fixup")
469 int BPF_PROG(hid_rdesc_fixup, struct hid_bpf_ctx *hctx)
470 {
471 ....
472 data[39] = 0x31;
473 data[41] = 0x30;
474 return 0;
475 }
476
477 Of course this can be also done within the kernel source code, see e.g.
478 `drivers/hid/hid-aureal.c` or `drivers/hid/hid-samsung.c` for a slightly
479 more complex file.
480
481 Check Documentation/hid/hidreport-parsing.rst if you need any help
482 navigating the HID manuals and understanding the exact meaning of
483 the HID report descriptor hex numbers.
484
485 Whatever solution you come up with, please remember to **submit the
486 fix to the HID maintainers**, so that it can be directly integrated in
487 the kernel and that particular HID device will start working for
488 everyone else. See Documentation/process/submitting-patches.rst for
489 guidelines on how to do this.
490
491
492 Modifying the transmitted data on the fly
493 -----------------------------------------
494
495 Using eBPF it is also possible to modify the data exchanged with the
496 device. See again the examples in `samples/hid`.
497
498 Again, **please post your fix**, so that it can be integrated in the
499 kernel!
500
501 Writing a specialized driver
502 ----------------------------
503
504 This should really be your last resort.
505
506
507 .. rubric:: Footnotes
508
509 .. [#hidraw] read hidraw: see Documentation/hid/hidraw.rst and
510 file `samples/hidraw/hid-example.c` for an example.
511 The output of ``hid-example`` would be, for the same mouse::
512
513 $ sudo ./hid-example
514 Report Descriptor Size: 52
515 Report Descriptor:
516 5 1 9 2 a1 1 9 1 a1 0 5 9 19 1 29 3 15 0 25 1 75 1 95 3 81 2 75 5 95 1 81 1 5 1 9 30 9 31 9 38 15 81 25 7f 75 8 95 3 81 6 c0 c0
517
518 Raw Name: PixArt USB Optical Mouse
519 Raw Phys: usb-0000:05:00.4-2.3/input0
520 Raw Info:
521 bustype: 3 (USB)
522 vendor: 0x093a
523 product: 0x2510
524 ...
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.