€•1½      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”(hhŒparent”hubaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ%/translations/zh_CN/hid/hid-transport”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”(hhhh2ubah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/zh_TW/hid/hid-transport”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”(hhhhFubah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/it_IT/hid/hid-transport”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”(hhhhZubah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/ja_JP/hid/hid-transport”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”(hhhhnubah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/ko_KR/hid/hid-transport”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”(hhhh‚ubah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ%/translations/sp_SP/hid/hid-transport”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒHID I/O Transport Drivers”h]”hŒHID I/O Transport Drivers”…””}”(hhªhh¨hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hh£hžhhŸŒ?/var/lib/git/docbuild/linux/Documentation/hid/hid-transport.rst”h KubhŒ	paragraph”“”)”}”(hX  The HID subsystem is independent of the underlying transport driver. Initially,
only USB was supported, but other specifications adopted the HID design and
provided new transport drivers. The kernel includes at least support for USB,
Bluetooth, I2C and user-space I/O drivers.”h]”hX  The HID subsystem is independent of the underlying transport driver. Initially,
only USB was supported, but other specifications adopted the HID design and
provided new transport drivers. The kernel includes at least support for USB,
Bluetooth, I2C and user-space I/O drivers.”…””}”(hh»hh¹hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khh£hžhubh¢)”}”(hhh]”(h§)”}”(hŒ
1) HID Bus”h]”hŒ
1) HID Bus”…””}”(hhÌhhÊhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hhÇhžhhŸh¶h Kubh¸)”}”(hX°  The HID subsystem is designed as a bus. Any I/O subsystem may provide HID
devices and register them with the HID bus. HID core then loads generic device
drivers on top of it. The transport drivers are responsible for raw data
transport and device setup/management. HID core is responsible for
report-parsing, report interpretation and the user-space API. Device specifics
and quirks are handled by all layers depending on the quirk.”h]”hX°  The HID subsystem is designed as a bus. Any I/O subsystem may provide HID
devices and register them with the HID bus. HID core then loads generic device
drivers on top of it. The transport drivers are responsible for raw data
transport and device setup/management. HID core is responsible for
report-parsing, report interpretation and the user-space API. Device specifics
and quirks are handled by all layers depending on the quirk.”…””}”(hhÚhhØhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KhhÇhžhubhŒliteral_block”“”)”}”(hX›  +-----------+  +-----------+            +-----------+  +-----------+
| Device #1 |  | Device #i |            | Device #j |  | Device #k |
+-----------+  +-----------+            +-----------+  +-----------+
         \\      //                              \\      //
       +------------+                          +------------+
       | I/O Driver |                          | I/O Driver |
       +------------+                          +------------+
             ||                                      ||
    +------------------+                    +------------------+
    | Transport Driver |                    | Transport Driver |
    +------------------+                    +------------------+
                      \___                ___/
                          \              /
                         +----------------+
                         |    HID Core    |
                         +----------------+
                          /  |        |  \
                         /   |        |   \
            ____________/    |        |    \_________________
           /                 |        |                      \
          /                  |        |                       \
+----------------+  +-----------+  +------------------+  +------------------+
| Generic Driver |  | MT Driver |  | Custom Driver #1 |  | Custom Driver #2 |
+----------------+  +-----------+  +------------------+  +------------------+”h]”hX›  +-----------+  +-----------+            +-----------+  +-----------+
| Device #1 |  | Device #i |            | Device #j |  | Device #k |
+-----------+  +-----------+            +-----------+  +-----------+
         \\      //                              \\      //
       +------------+                          +------------+
       | I/O Driver |                          | I/O Driver |
       +------------+                          +------------+
             ||                                      ||
    +------------------+                    +------------------+
    | Transport Driver |                    | Transport Driver |
    +------------------+                    +------------------+
                      \___                ___/
                          \              /
                         +----------------+
                         |    HID Core    |
                         +----------------+
                          /  |        |  \
                         /   |        |   \
            ____________/    |        |    \_________________
           /                 |        |                      \
          /                  |        |                       \
+----------------+  +-----------+  +------------------+  +------------------+
| Generic Driver |  | MT Driver |  | Custom Driver #1 |  | Custom Driver #2 |
+----------------+  +-----------+  +------------------+  +------------------+”…””}”(hhhhèubah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1hæhŸh¶h KhhÇhžhubh¸)”}”(hŒExample Drivers:”h]”hŒExample Drivers:”…””}”(hhúhhøhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K/hhÇhžhubhŒblock_quote”“”)”}”(hhh]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hŒI/O: USB, I2C, Bluetooth-l2cap”h]”h¸)”}”(hj  h]”hŒI/O: USB, I2C, Bluetooth-l2cap”…””}”(hj  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K1hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubj  )”}”(hŒ%Transport: USB-HID, I2C-HID, BT-HIDP
”h]”h¸)”}”(hŒ$Transport: USB-HID, I2C-HID, BT-HIDP”h]”hŒ$Transport: USB-HID, I2C-HID, BT-HIDP”…””}”(hj/  hj-  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K2hj)  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ-”uh1j  hŸh¶h K1hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hhÇhžhhŸNh Nubh¸)”}”(hŒEverything below "HID Core" is simplified in this graph as it is only of
interest to HID device drivers. Transport drivers do not need to know the
specifics.”h]”hŒ¡Everything below â€œHID Coreâ€ is simplified in this graph as it is only of
interest to HID device drivers. Transport drivers do not need to know the
specifics.”…””}”(hjQ  hjO  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K4hhÇhžhubh¢)”}”(hhh]”(h§)”}”(hŒ1.1) Device Setup”h]”hŒ1.1) Device Setup”…””}”(hjb  hj`  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj]  hžhhŸh¶h K9ubh¸)”}”(hXª  I/O drivers normally provide hotplug detection or device enumeration APIs to the
transport drivers. Transport drivers use this to find any suitable HID device.
They allocate HID device objects and register them with HID core. Transport
drivers are not required to register themselves with HID core. HID core is never
aware of which transport drivers are available and is not interested in it. It
is only interested in devices.”h]”hXª  I/O drivers normally provide hotplug detection or device enumeration APIs to the
transport drivers. Transport drivers use this to find any suitable HID device.
They allocate HID device objects and register them with HID core. Transport
drivers are not required to register themselves with HID core. HID core is never
aware of which transport drivers are available and is not interested in it. It
is only interested in devices.”…””}”(hjp  hjn  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K;hj]  hžhubh¸)”}”(hŒÚTransport drivers attach a constant "struct hid_ll_driver" object with each
device. Once a device is registered with HID core, the callbacks provided via
this struct are used by HID core to communicate with the device.”h]”hŒÞTransport drivers attach a constant â€œstruct hid_ll_driverâ€ object with each
device. Once a device is registered with HID core, the callbacks provided via
this struct are used by HID core to communicate with the device.”…””}”(hj~  hj|  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KBhj]  hžhubh¸)”}”(hXH  Transport drivers are responsible for detecting device failures and unplugging.
HID core will operate a device as long as it is registered regardless of any
device failures. Once transport drivers detect unplug or failure events, they
must unregister the device from HID core and HID core will stop using the
provided callbacks.”h]”hXH  Transport drivers are responsible for detecting device failures and unplugging.
HID core will operate a device as long as it is registered regardless of any
device failures. Once transport drivers detect unplug or failure events, they
must unregister the device from HID core and HID core will stop using the
provided callbacks.”…””}”(hjŒ  hjŠ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KFhj]  hžhubeh}”(h]”Œdevice-setup”ah ]”h"]”Œ1.1) device setup”ah$]”h&]”uh1h¡hhÇhžhhŸh¶h K9ubh¢)”}”(hhh]”(h§)”}”(hŒ"1.2) Transport Driver Requirements”h]”hŒ"1.2) Transport Driver Requirements”…””}”(hj¥  hj£  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj   hžhhŸh¶h KMubh¸)”}”(hXí  The terms "asynchronous" and "synchronous" in this document describe the
transmission behavior regarding acknowledgements. An asynchronous channel must
not perform any synchronous operations like waiting for acknowledgements or
verifications. Generally, HID calls operating on asynchronous channels must be
running in atomic-context just fine.
On the other hand, synchronous channels can be implemented by the transport
driver in whatever way they like. They might just be the same as asynchronous
channels, but they can also provide acknowledgement reports, automatic
retransmission on failure, etc. in a blocking manner. If such functionality is
required on asynchronous channels, a transport-driver must implement that via
its own worker threads.”h]”hXõ  The terms â€œasynchronousâ€ and â€œsynchronousâ€ in this document describe the
transmission behavior regarding acknowledgements. An asynchronous channel must
not perform any synchronous operations like waiting for acknowledgements or
verifications. Generally, HID calls operating on asynchronous channels must be
running in atomic-context just fine.
On the other hand, synchronous channels can be implemented by the transport
driver in whatever way they like. They might just be the same as asynchronous
channels, but they can also provide acknowledgement reports, automatic
retransmission on failure, etc. in a blocking manner. If such functionality is
required on asynchronous channels, a transport-driver must implement that via
its own worker threads.”…””}”(hj³  hj±  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KOhj   hžhubh¸)”}”(hXØ  HID core requires transport drivers to follow a given design. A Transport
driver must provide two bi-directional I/O channels to each HID device. These
channels must not necessarily be bi-directional in the hardware itself. A
transport driver might just provide 4 uni-directional channels. Or it might
multiplex all four on a single physical channel. However, in this document we
will describe them as two bi-directional channels as they have several
properties in common.”h]”hXØ  HID core requires transport drivers to follow a given design. A Transport
driver must provide two bi-directional I/O channels to each HID device. These
channels must not necessarily be bi-directional in the hardware itself. A
transport driver might just provide 4 uni-directional channels. Or it might
multiplex all four on a single physical channel. However, in this document we
will describe them as two bi-directional channels as they have several
properties in common.”…””}”(hjÁ  hj¿  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K[hj   hžhubj  )”}”(hhh]”j  )”}”(hhh]”(j  )”}”(hX§  Interrupt Channel (intr): The intr channel is used for asynchronous data
reports. No management commands or data acknowledgements are sent on this
channel. Any unrequested incoming or outgoing data report must be sent on
this channel and is never acknowledged by the remote side. Devices usually
send their input events on this channel. Outgoing events are normally
not sent via intr, except if high throughput is required.”h]”h¸)”}”(hX§  Interrupt Channel (intr): The intr channel is used for asynchronous data
reports. No management commands or data acknowledgements are sent on this
channel. Any unrequested incoming or outgoing data report must be sent on
this channel and is never acknowledged by the remote side. Devices usually
send their input events on this channel. Outgoing events are normally
not sent via intr, except if high throughput is required.”h]”hX§  Interrupt Channel (intr): The intr channel is used for asynchronous data
reports. No management commands or data acknowledgements are sent on this
channel. Any unrequested incoming or outgoing data report must be sent on
this channel and is never acknowledged by the remote side. Devices usually
send their input events on this channel. Outgoing events are normally
not sent via intr, except if high throughput is required.”…””}”(hjÙ  hj×  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KchjÓ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjÐ  ubj  )”}”(hXä  Control Channel (ctrl): The ctrl channel is used for synchronous requests and
device management. Unrequested data input events must not be sent on this
channel and are normally ignored. Instead, devices only send management
events or answers to host requests on this channel.
The control-channel is used for direct blocking queries to the device
independent of any events on the intr-channel.
Outgoing reports are usually sent on the ctrl channel via synchronous
SET_REPORT requests.
”h]”h¸)”}”(hXã  Control Channel (ctrl): The ctrl channel is used for synchronous requests and
device management. Unrequested data input events must not be sent on this
channel and are normally ignored. Instead, devices only send management
events or answers to host requests on this channel.
The control-channel is used for direct blocking queries to the device
independent of any events on the intr-channel.
Outgoing reports are usually sent on the ctrl channel via synchronous
SET_REPORT requests.”h]”hXã  Control Channel (ctrl): The ctrl channel is used for synchronous requests and
device management. Unrequested data input events must not be sent on this
channel and are normally ignored. Instead, devices only send management
events or answers to host requests on this channel.
The control-channel is used for direct blocking queries to the device
independent of any events on the intr-channel.
Outgoing reports are usually sent on the ctrl channel via synchronous
SET_REPORT requests.”…””}”(hjñ  hjï  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kihjë  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjÐ  ubeh}”(h]”h ]”h"]”h$]”h&]”jG  jH  uh1j  hŸh¶h KchjÍ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   hžhhŸNh Nubh¸)”}”(hŒqCommunication between devices and HID core is mostly done via HID reports. A
report can be of one of three types:”h]”hŒqCommunication between devices and HID core is mostly done via HID reports. A
report can be of one of three types:”…””}”(hj  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Krhj   hžhubj  )”}”(hhh]”j  )”}”(hhh]”(j  )”}”(hX.  INPUT Report: Input reports provide data from device to host. This
data may include button events, axis events, battery status or more. This
data is generated by the device and sent to the host with or without
requiring explicit requests. Devices can choose to send data continuously or
only on change.”h]”h¸)”}”(hX.  INPUT Report: Input reports provide data from device to host. This
data may include button events, axis events, battery status or more. This
data is generated by the device and sent to the host with or without
requiring explicit requests. Devices can choose to send data continuously or
only on change.”h]”hX.  INPUT Report: Input reports provide data from device to host. This
data may include button events, axis events, battery status or more. This
data is generated by the device and sent to the host with or without
requiring explicit requests. Devices can choose to send data continuously or
only on change.”…””}”(hj)  hj'  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kuhj#  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   ubj  )”}”(hX;  OUTPUT Report: Output reports change device states. They are sent from host
to device and may include LED requests, rumble requests or more. Output
reports are never sent from device to host, but a host can retrieve their
current state.
Hosts may choose to send output reports either continuously or only on
change.”h]”h¸)”}”(hX;  OUTPUT Report: Output reports change device states. They are sent from host
to device and may include LED requests, rumble requests or more. Output
reports are never sent from device to host, but a host can retrieve their
current state.
Hosts may choose to send output reports either continuously or only on
change.”h]”hX;  OUTPUT Report: Output reports change device states. They are sent from host
to device and may include LED requests, rumble requests or more. Output
reports are never sent from device to host, but a host can retrieve their
current state.
Hosts may choose to send output reports either continuously or only on
change.”…””}”(hjA  hj?  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kzhj;  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   ubj  )”}”(hX–  FEATURE Report: Feature reports are used for specific static device features
and never reported spontaneously. A host can read and/or write them to access
data like battery-state or device-settings.
Feature reports are never sent without requests. A host must explicitly set
or retrieve a feature report. This also means, feature reports are never sent
on the intr channel as this channel is asynchronous.
”h]”h¸)”}”(hX•  FEATURE Report: Feature reports are used for specific static device features
and never reported spontaneously. A host can read and/or write them to access
data like battery-state or device-settings.
Feature reports are never sent without requests. A host must explicitly set
or retrieve a feature report. This also means, feature reports are never sent
on the intr channel as this channel is asynchronous.”h]”hX•  FEATURE Report: Feature reports are used for specific static device features
and never reported spontaneously. A host can read and/or write them to access
data like battery-state or device-settings.
Feature reports are never sent without requests. A host must explicitly set
or retrieve a feature report. This also means, feature reports are never sent
on the intr channel as this channel is asynchronous.”…””}”(hjY  hjW  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K€hjS  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   ubeh}”(h]”h ]”h"]”h$]”h&]”jG  jH  uh1j  hŸh¶h Kuhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   hžhhŸNh Nubh¸)”}”(hXg  INPUT and OUTPUT reports can be sent as pure data reports on the intr channel.
For INPUT reports this is the usual operational mode. But for OUTPUT reports,
this is rarely done as OUTPUT reports are normally quite scarce. But devices are
free to make excessive use of asynchronous OUTPUT reports (for instance, custom
HID audio speakers make great use of it).”h]”hXg  INPUT and OUTPUT reports can be sent as pure data reports on the intr channel.
For INPUT reports this is the usual operational mode. But for OUTPUT reports,
this is rarely done as OUTPUT reports are normally quite scarce. But devices are
free to make excessive use of asynchronous OUTPUT reports (for instance, custom
HID audio speakers make great use of it).”…””}”(hjy  hjw  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K‡hj   hžhubh¸)”}”(hŒÜPlain reports must not be sent on the ctrl channel, though. Instead, the ctrl
channel provides synchronous GET/SET_REPORT requests. Plain reports are only
allowed on the intr channel and are the only means of data there.”h]”hŒÜPlain reports must not be sent on the ctrl channel, though. Instead, the ctrl
channel provides synchronous GET/SET_REPORT requests. Plain reports are only
allowed on the intr channel and are the only means of data there.”…””}”(hj‡  hj…  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khj   hžhubj  )”}”(hhh]”j  )”}”(hhh]”(j  )”}”(hX¤  GET_REPORT: A GET_REPORT request has a report ID as payload and is sent
from host to device. The device must answer with a data report for the
requested report ID on the ctrl channel as a synchronous acknowledgement.
Only one GET_REPORT request can be pending for each device. This restriction
is enforced by HID core as several transport drivers don't allow multiple
simultaneous GET_REPORT requests.
Note that data reports which are sent as answer to a GET_REPORT request are
not handled as generic device events. That is, if a device does not operate
in continuous data reporting mode, an answer to GET_REPORT does not replace
the raw data report on the intr channel on state change.
GET_REPORT is only used by custom HID device drivers to query device state.
Normally, HID core caches any device state so this request is not necessary
on devices that follow the HID specs except during device initialization to
retrieve the current state.
GET_REPORT requests can be sent for any of the 3 report types and shall
return the current report state of the device. However, OUTPUT reports as
payload may be blocked by the underlying transport driver if the
specification does not allow them.”h]”h¸)”}”(hX¤  GET_REPORT: A GET_REPORT request has a report ID as payload and is sent
from host to device. The device must answer with a data report for the
requested report ID on the ctrl channel as a synchronous acknowledgement.
Only one GET_REPORT request can be pending for each device. This restriction
is enforced by HID core as several transport drivers don't allow multiple
simultaneous GET_REPORT requests.
Note that data reports which are sent as answer to a GET_REPORT request are
not handled as generic device events. That is, if a device does not operate
in continuous data reporting mode, an answer to GET_REPORT does not replace
the raw data report on the intr channel on state change.
GET_REPORT is only used by custom HID device drivers to query device state.
Normally, HID core caches any device state so this request is not necessary
on devices that follow the HID specs except during device initialization to
retrieve the current state.
GET_REPORT requests can be sent for any of the 3 report types and shall
return the current report state of the device. However, OUTPUT reports as
payload may be blocked by the underlying transport driver if the
specification does not allow them.”h]”hX¦  GET_REPORT: A GET_REPORT request has a report ID as payload and is sent
from host to device. The device must answer with a data report for the
requested report ID on the ctrl channel as a synchronous acknowledgement.
Only one GET_REPORT request can be pending for each device. This restriction
is enforced by HID core as several transport drivers donâ€™t allow multiple
simultaneous GET_REPORT requests.
Note that data reports which are sent as answer to a GET_REPORT request are
not handled as generic device events. That is, if a device does not operate
in continuous data reporting mode, an answer to GET_REPORT does not replace
the raw data report on the intr channel on state change.
GET_REPORT is only used by custom HID device drivers to query device state.
Normally, HID core caches any device state so this request is not necessary
on devices that follow the HID specs except during device initialization to
retrieve the current state.
GET_REPORT requests can be sent for any of the 3 report types and shall
return the current report state of the device. However, OUTPUT reports as
payload may be blocked by the underlying transport driver if the
specification does not allow them.”…””}”(hjŸ  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K‘hj™  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj–  ubj  )”}”(hX¹  SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is
sent from host to device and a device must update its current report state
according to the given data. Any of the 3 report types can be used. However,
INPUT reports as payload might be blocked by the underlying transport driver
if the specification does not allow them.
A device must answer with a synchronous acknowledgement. However, HID core
does not require transport drivers to forward this acknowledgement to HID
core.
Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This
restriction is enforced by HID core as some transport drivers do not support
multiple synchronous SET_REPORT requests.
”h]”h¸)”}”(hX¸  SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is
sent from host to device and a device must update its current report state
according to the given data. Any of the 3 report types can be used. However,
INPUT reports as payload might be blocked by the underlying transport driver
if the specification does not allow them.
A device must answer with a synchronous acknowledgement. However, HID core
does not require transport drivers to forward this acknowledgement to HID
core.
Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This
restriction is enforced by HID core as some transport drivers do not support
multiple synchronous SET_REPORT requests.”h]”hX¸  SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is
sent from host to device and a device must update its current report state
according to the given data. Any of the 3 report types can be used. However,
INPUT reports as payload might be blocked by the underlying transport driver
if the specification does not allow them.
A device must answer with a synchronous acknowledgement. However, HID core
does not require transport drivers to forward this acknowledgement to HID
core.
Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This
restriction is enforced by HID core as some transport drivers do not support
multiple synchronous SET_REPORT requests.”…””}”(hj·  hjµ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K£hj±  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj–  ubeh}”(h]”h ]”h"]”h$]”h&]”jG  jH  uh1j  hŸh¶h K‘hj“  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   hžhhŸNh Nubh¸)”}”(hŒˆOther ctrl-channel requests are supported by USB-HID but are not available
(or deprecated) in most other transport level specifications:”h]”hŒˆOther ctrl-channel requests are supported by USB-HID but are not available
(or deprecated) in most other transport level specifications:”…””}”(hj×  hjÕ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K¯hj   hžhubj  )”}”(hhh]”j  )”}”(hhh]”(j  )”}”(hŒ/GET/SET_IDLE: Only used by USB-HID and I2C-HID.”h]”h¸)”}”(hjë  h]”hŒ/GET/SET_IDLE: Only used by USB-HID and I2C-HID.”…””}”(hjë  hjí  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K²hjé  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjæ  ubj  )”}”(hŒ'GET/SET_PROTOCOL: Not used by HID core.”h]”h¸)”}”(hj  h]”hŒ'GET/SET_PROTOCOL: Not used by HID core.”…””}”(hj  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K³hj   ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjæ  ubj  )”}”(hŒ2RESET: Used by I2C-HID, not hooked up in HID core.”h]”h¸)”}”(hj  h]”hŒ2RESET: Used by I2C-HID, not hooked up in HID core.”…””}”(hj  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K´hj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjæ  ubj  )”}”(hŒ7SET_POWER: Used by I2C-HID, not hooked up in HID core.
”h]”h¸)”}”(hŒ6SET_POWER: Used by I2C-HID, not hooked up in HID core.”h]”hŒ6SET_POWER: Used by I2C-HID, not hooked up in HID core.”…””}”(hj4  hj2  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kµhj.  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hjæ  ubeh}”(h]”h ]”h"]”h$]”h&]”jG  jH  uh1j  hŸh¶h K²hjã  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j  hj   hžhhŸNh Nubeh}”(h]”Œtransport-driver-requirements”ah ]”h"]”Œ"1.2) transport driver requirements”ah$]”h&]”uh1h¡hhÇhžhhŸh¶h KMubeh}”(h]”Œhid-bus”ah ]”h"]”Œ
1) hid bus”ah$]”h&]”uh1h¡hh£hžhhŸh¶h Kubh¢)”}”(hhh]”(h§)”}”(hŒ
2) HID API”h]”hŒ
2) HID API”…””}”(hjg  hje  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjb  hžhhŸh¶h K¸ubh¢)”}”(hhh]”(h§)”}”(hŒ2.1) Initialization”h]”hŒ2.1) Initialization”…””}”(hjx  hjv  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjs  hžhhŸh¶h K»ubh¸)”}”(hŒ_Transport drivers normally use the following procedure to register a new device
with HID core::”h]”hŒ^Transport drivers normally use the following procedure to register a new device
with HID core:”…””}”(hŒ^Transport drivers normally use the following procedure to register a new device
with HID core:”hj„  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K½hjs  hžhubhç)”}”(hX“  struct hid_device *hid;
int ret;

hid = hid_allocate_device();
if (IS_ERR(hid)) {
        ret = PTR_ERR(hid);
        goto err_<...>;
}

strscpy(hid->name, <device-name-src>, sizeof(hid->name));
strscpy(hid->phys, <device-phys-src>, sizeof(hid->phys));
strscpy(hid->uniq, <device-uniq-src>, sizeof(hid->uniq));

hid->ll_driver = &custom_ll_driver;
hid->bus = <device-bus>;
hid->vendor = <device-vendor>;
hid->product = <device-product>;
hid->version = <device-version>;
hid->country = <device-country>;
hid->dev.parent = <pointer-to-parent-device>;
hid->driver_data = <transport-driver-data-field>;

ret = hid_add_device(hid);
if (ret)
        goto err_<...>;”h]”hX“  struct hid_device *hid;
int ret;

hid = hid_allocate_device();
if (IS_ERR(hid)) {
        ret = PTR_ERR(hid);
        goto err_<...>;
}

strscpy(hid->name, <device-name-src>, sizeof(hid->name));
strscpy(hid->phys, <device-phys-src>, sizeof(hid->phys));
strscpy(hid->uniq, <device-uniq-src>, sizeof(hid->uniq));

hid->ll_driver = &custom_ll_driver;
hid->bus = <device-bus>;
hid->vendor = <device-vendor>;
hid->product = <device-product>;
hid->version = <device-version>;
hid->country = <device-country>;
hid->dev.parent = <pointer-to-parent-device>;
hid->driver_data = <transport-driver-data-field>;

ret = hid_add_device(hid);
if (ret)
        goto err_<...>;”…””}”(hhhj“  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h KÀhjs  hžhubh¸)”}”(hŒÃOnce hid_add_device() is entered, HID core might use the callbacks provided in
"custom_ll_driver". Note that fields like "country" can be ignored by underlying
transport-drivers if not supported.”h]”hŒËOnce hid_add_device() is entered, HID core might use the callbacks provided in
â€œcustom_ll_driverâ€. Note that fields like â€œcountryâ€ can be ignored by underlying
transport-drivers if not supported.”…””}”(hj£  hj¡  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÚhjs  hžhubh¸)”}”(hŒTo unregister a device, use::”h]”hŒTo unregister a device, use:”…””}”(hŒTo unregister a device, use:”hj¯  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÞhjs  hžhubhç)”}”(hŒhid_destroy_device(hid);”h]”hŒhid_destroy_device(hid);”…””}”(hhhj¾  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Kàhjs  hžhubh¸)”}”(hŒ\Once hid_destroy_device() returns, HID core will no longer make use of any
driver callbacks.”h]”hŒ\Once hid_destroy_device() returns, HID core will no longer make use of any
driver callbacks.”…””}”(hjÎ  hjÌ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kâhjs  hžhubeh}”(h]”Œinitialization”ah ]”h"]”Œ2.1) initialization”ah$]”h&]”uh1h¡hjb  hžhhŸh¶h K»ubh¢)”}”(hhh]”(h§)”}”(hŒ2.2) hid_ll_driver operations”h]”hŒ2.2) hid_ll_driver operations”…””}”(hjç  hjå  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjâ  hžhhŸh¶h Kæubh¸)”}”(hŒ The available HID callbacks are:”h]”hŒ The available HID callbacks are:”…””}”(hjõ  hjó  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kèhjâ  hžhubj  )”}”(hhh]”(hç)”}”(hŒ&int (*start) (struct hid_device *hdev)”h]”hŒ&int (*start) (struct hid_device *hdev)”…””}”(hhhj  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Kìhj  ubh¸)”}”(hX  Called from HID device drivers once they want to use the device. Transport
drivers can choose to setup their device in this callback. However, normally
devices are already set up before transport drivers register them to HID core
so this is mostly only used by USB-HID.”h]”hX  Called from HID device drivers once they want to use the device. Transport
drivers can choose to setup their device in this callback. However, normally
devices are already set up before transport drivers register them to HID core
so this is mostly only used by USB-HID.”…””}”(hj  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kîhj  ubhç)”}”(hŒ&void (*stop) (struct hid_device *hdev)”h]”hŒ&void (*stop) (struct hid_device *hdev)”…””}”(hhhj   ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Kõhj  ubh¸)”}”(hŒèCalled from HID device drivers once they are done with a device. Transport
drivers can free any buffers and deinitialize the device. But note that
->start() might be called again if another HID device driver is loaded on the
device.”h]”hŒèCalled from HID device drivers once they are done with a device. Transport
drivers can free any buffers and deinitialize the device. But note that
->start() might be called again if another HID device driver is loaded on the
device.”…””}”(hj0  hj.  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K÷hj  ubh¸)”}”(hŒtTransport drivers are free to ignore it and deinitialize devices after they
destroyed them via hid_destroy_device().”h]”hŒtTransport drivers are free to ignore it and deinitialize devices after they
destroyed them via hid_destroy_device().”…””}”(hj>  hj<  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kühj  ubhç)”}”(hŒ%int (*open) (struct hid_device *hdev)”h]”hŒ%int (*open) (struct hid_device *hdev)”…””}”(hhhjJ  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Mhj  ubh¸)”}”(hXq  Called from HID device drivers once they are interested in data reports.
Usually, while user-space didn't open any input API/etc., device drivers are
not interested in device data and transport drivers can put devices asleep.
However, once ->open() is called, transport drivers must be ready for I/O.
->open() calls are nested for each client that opens the HID device.”h]”hXs  Called from HID device drivers once they are interested in data reports.
Usually, while user-space didnâ€™t open any input API/etc., device drivers are
not interested in device data and transport drivers can put devices asleep.
However, once ->open() is called, transport drivers must be ready for I/O.
->open() calls are nested for each client that opens the HID device.”…””}”(hjZ  hjX  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  ubhç)”}”(hŒ'void (*close) (struct hid_device *hdev)”h]”hŒ'void (*close) (struct hid_device *hdev)”…””}”(hhhjf  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Mhj  ubh¸)”}”(hŒ­Called from HID device drivers after ->open() was called but they are no
longer interested in device reports. (Usually if user-space closed any input
devices of the driver).”h]”hŒ­Called from HID device drivers after ->open() was called but they are no
longer interested in device reports. (Usually if user-space closed any input
devices of the driver).”…””}”(hjv  hjt  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  ubh¸)”}”(hŒÞTransport drivers can put devices asleep and terminate any I/O of all
->open() calls have been followed by a ->close() call. However, ->start() may
be called again if the device driver is interested in input reports again.”h]”hŒÞTransport drivers can put devices asleep and terminate any I/O of all
->open() calls have been followed by a ->close() call. However, ->start() may
be called again if the device driver is interested in input reports again.”…””}”(hj„  hj‚  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  ubhç)”}”(hŒ&int (*parse) (struct hid_device *hdev)”h]”hŒ&int (*parse) (struct hid_device *hdev)”…””}”(hhhj  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Mhj  ubh¸)”}”(hŒ¹Called once during device setup after ->start() has been called. Transport
drivers must read the HID report-descriptor from the device and tell HID core
about it via hid_parse_report().”h]”hŒ¹Called once during device setup after ->start() has been called. Transport
drivers must read the HID report-descriptor from the device and tell HID core
about it via hid_parse_report().”…””}”(hj   hjž  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj  ubhç)”}”(hŒ1int (*power) (struct hid_device *hdev, int level)”h]”hŒ1int (*power) (struct hid_device *hdev, int level)”…””}”(hhhj¬  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h Mhj  ubh¸)”}”(hŒ‡Called by HID core to give PM hints to transport drivers. Usually this is
analogical to the ->open() and ->close() hints and redundant.”h]”hŒ‡Called by HID core to give PM hints to transport drivers. Usually this is
analogical to the ->open() and ->close() hints and redundant.”…””}”(hj¼  hjº  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M!hj  ubhç)”}”(hŒbvoid (*request) (struct hid_device *hdev, struct hid_report *report,
                 int reqtype)”h]”hŒbvoid (*request) (struct hid_device *hdev, struct hid_report *report,
                 int reqtype)”…””}”(hhhjÈ  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h M&hj  ubh¸)”}”(hŒ¶Send a HID request on the ctrl channel. "report" contains the report that
should be sent and "reqtype" the request type. Request-type can be
HID_REQ_SET_REPORT or HID_REQ_GET_REPORT.”h]”hŒ¾Send a HID request on the ctrl channel. â€œreportâ€ contains the report that
should be sent and â€œreqtypeâ€ the request type. Request-type can be
HID_REQ_SET_REPORT or HID_REQ_GET_REPORT.”…””}”(hjØ  hjÖ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M)hj  ubh¸)”}”(hŒÔThis callback is optional. If not provided, HID core will assemble a raw
report following the HID specs and send it via the ->raw_request() callback.
The transport driver is free to implement this asynchronously.”h]”hŒÔThis callback is optional. If not provided, HID core will assemble a raw
report following the HID specs and send it via the ->raw_request() callback.
The transport driver is free to implement this asynchronously.”…””}”(hjæ  hjä  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M-hj  ubhç)”}”(hŒ%int (*wait) (struct hid_device *hdev)”h]”hŒ%int (*wait) (struct hid_device *hdev)”…””}”(hhhjò  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h M3hj  ubh¸)”}”(hŒ§Used by HID core before calling ->request() again. A transport driver can use
it to wait for any pending requests to complete if only one request is
allowed at a time.”h]”hŒ§Used by HID core before calling ->request() again. A transport driver can use
it to wait for any pending requests to complete if only one request is
allowed at a time.”…””}”(hj  hj   hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M5hj  ubhç)”}”(hŒ¨int (*raw_request) (struct hid_device *hdev, unsigned char reportnum,
                    __u8 *buf, size_t count, unsigned char rtype,
                    int reqtype)”h]”hŒ¨int (*raw_request) (struct hid_device *hdev, unsigned char reportnum,
                    __u8 *buf, size_t count, unsigned char rtype,
                    int reqtype)”…””}”(hhhj  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h M;hj  ubh¸)”}”(hŒñSame as ->request() but provides the report as raw buffer. This request shall
be synchronous. A transport driver must not use ->wait() to complete such
requests. This request is mandatory and hid core will reject the device if
it is missing.”h]”hŒñSame as ->request() but provides the report as raw buffer. This request shall
be synchronous. A transport driver must not use ->wait() to complete such
requests. This request is mandatory and hid core will reject the device if
it is missing.”…””}”(hj  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M?hj  ubhç)”}”(hŒEint (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len)”h]”hŒEint (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len)”…””}”(hhhj*  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h MFhj  ubh¸)”}”(hX  Send raw output report via intr channel. Used by some HID device drivers
which require high throughput for outgoing requests on the intr channel. This
must not cause SET_REPORT calls! This must be implemented as asynchronous
output report on the intr channel!”h]”hX  Send raw output report via intr channel. Used by some HID device drivers
which require high throughput for outgoing requests on the intr channel. This
must not cause SET_REPORT calls! This must be implemented as asynchronous
output report on the intr channel!”…””}”(hj:  hj8  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MHhj  ubhç)”}”(hŒHint (*idle) (struct hid_device *hdev, int report, int idle, int reqtype)”h]”hŒHint (*idle) (struct hid_device *hdev, int report, int idle, int reqtype)”…””}”(hhhjF  ubah}”(h]”h ]”h"]”h$]”h&]”höh÷uh1hæhŸh¶h MOhj  ubh¸)”}”(hŒEPerform SET/GET_IDLE request. Only used by USB-HID, do not implement!”h]”hŒEPerform SET/GET_IDLE request. Only used by USB-HID, do not implement!”…””}”(hjV  hjT  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MQhj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j  hjâ  hžhhŸh¶h Nubeh}”(h]”Œhid-ll-driver-operations”ah ]”h"]”Œ2.2) hid_ll_driver operations”ah$]”h&]”uh1h¡hjb  hžhhŸh¶h Kæubh¢)”}”(hhh]”(h§)”}”(hŒ2.3) Data Path”h]”hŒ2.3) Data Path”…””}”(hju  hjs  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjp  hžhhŸh¶h MTubh¸)”}”(hX  Transport drivers are responsible of reading data from I/O devices. They must
handle any I/O-related state-tracking themselves. HID core does not implement
protocol handshakes or other management commands which can be required by the
given HID transport specification.”h]”hX  Transport drivers are responsible of reading data from I/O devices. They must
handle any I/O-related state-tracking themselves. HID core does not implement
protocol handshakes or other management commands which can be required by the
given HID transport specification.”…””}”(hjƒ  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MVhjp  hžhubh¸)”}”(hŒúEvery raw data packet read from a device must be fed into HID core via
hid_input_report(). You must specify the channel-type (intr or ctrl) and report
type (input/output/feature). Under normal conditions, only input reports are
provided via this API.”h]”hŒúEvery raw data packet read from a device must be fed into HID core via
hid_input_report(). You must specify the channel-type (intr or ctrl) and report
type (input/output/feature). Under normal conditions, only input reports are
provided via this API.”…””}”(hj‘  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M[hjp  hžhubh¸)”}”(hX   Responses to GET_REPORT requests via ->request() must also be provided via this
API. Responses to ->raw_request() are synchronous and must be intercepted by the
transport driver and not passed to hid_input_report().
Acknowledgements to SET_REPORT requests are not of interest to HID core.”h]”hX   Responses to GET_REPORT requests via ->request() must also be provided via this
API. Responses to ->raw_request() are synchronous and must be intercepted by the
transport driver and not passed to hid_input_report().
Acknowledgements to SET_REPORT requests are not of interest to HID core.”…””}”(hjŸ  hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M`hjp  hžhubhŒ
transition”“”)”}”(hŒ4----------------------------------------------------”h]”h}”(h]”h ]”h"]”h$]”h&]”uh1j«  hŸh¶h Mehjp  hžhubh¸)”}”(hŒ4Written 2013, David Herrmann <dh.herrmann@gmail.com>”h]”(hŒWritten 2013, David Herrmann <”…””}”(hŒWritten 2013, David Herrmann <”hj·  hžhhŸNh NubhŒ	reference”“”)”}”(hŒdh.herrmann@gmail.com”h]”hŒdh.herrmann@gmail.com”…””}”(hhhjÂ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefuri”Œmailto:dh.herrmann@gmail.com”uh1jÀ  hj·  ubhŒ>”…””}”(hŒ>”hj·  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mghjp  hžhubeh}”(h]”Œ	data-path”ah ]”h"]”Œ2.3) data path”ah$]”h&]”uh1h¡hjb  hžhhŸh¶h MTubeh}”(h]”Œhid-api”ah ]”h"]”Œ
2) hid api”ah$]”h&]”uh1h¡hh£hžhhŸh¶h K¸ubeh}”(h]”Œhid-i-o-transport-drivers”ah ]”h"]”Œhid i/o transport drivers”ah$]”h&]”uh1h¡hhhžhhŸh¶h Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”h¶uh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(h¦NŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”j  Œerror_encoding”ŒUTF-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”h¶Œ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œembed_images”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(jò  jï  j_  j\  j  jš  jW  jT  jê  jç  jß  jÜ  jm  jj  jâ  jß  uŒ	nametypes”}”(jò  Nj_  Nj  NjW  Njê  Njß  Njm  Njâ  Nuh}”(jï  h£j\  hÇjš  j]  jT  j   jç  jb  jÜ  js  jj  jâ  jß  jp  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nhžhub.