HID I/O Transport Drivers =========================== 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. 1) HID Bus ========== 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 of raw data transport and device setup/management. HID core is responsible of report-parsing, report interpretation and the user-space API. Device specifics and quirks are handled by all layers depending on the quirk. +-----------+ +-----------+ +-----------+ +-----------+ | 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 | +----------------+ +-----------+ +------------------+ +------------------+ Example Drivers: I/O: USB, I2C, Bluetooth-l2cap Transport: USB-HID, I2C-HID, BT-HIDP 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. 1.1) Device Setup ----------------- 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. 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. Transport drivers are responsible of 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. 1.2) Transport Driver Requirements ---------------------------------- 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 channel
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) 2017 OPNFV.


===========
Compass4NFV
===========

.. toctree::
   :maxdepth: 2

   ./overview/index.rst
   ./design/index.rst

Indices
=======
* :ref:`search`
ed by the given HID transport specification. 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. 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. ---------------------------------------------------- Written 2013, David Herrmann