318 lines
15 KiB
Plaintext
318 lines
15 KiB
Plaintext
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 channels, a transport-driver must implement that via
|
|
its own worker threads.
|
|
|
|
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.
|
|
|
|
- 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 send via intr, except if high throughput is required.
|
|
- 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.
|
|
|
|
Communication between devices and HID core is mostly done via HID reports. A
|
|
report can be of one of three types:
|
|
|
|
- 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.
|
|
- 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.
|
|
- 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.
|
|
|
|
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).
|
|
|
|
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.
|
|
|
|
- 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.
|
|
- 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 it's 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.
|
|
|
|
Other ctrl-channel requests are supported by USB-HID but are not available
|
|
(or deprecated) in most other transport level specifications:
|
|
|
|
- GET/SET_IDLE: Only used by USB-HID and I2C-HID.
|
|
- GET/SET_PROTOCOL: Not used by HID core.
|
|
- RESET: Used by I2C-HID, not hooked up in HID core.
|
|
- SET_POWER: Used by I2C-HID, not hooked up in HID core.
|
|
|
|
2) HID API
|
|
==========
|
|
|
|
2.1) Initialization
|
|
-------------------
|
|
|
|
Transport drivers normally use the following procedure to register a new device
|
|
with HID core:
|
|
|
|
struct hid_device *hid;
|
|
int ret;
|
|
|
|
hid = hid_allocate_device();
|
|
if (IS_ERR(hid)) {
|
|
ret = PTR_ERR(hid);
|
|
goto err_<...>;
|
|
}
|
|
|
|
strlcpy(hid->name, <device-name-src>, 127);
|
|
strlcpy(hid->phys, <device-phys-src>, 63);
|
|
strlcpy(hid->uniq, <device-uniq-src>, 63);
|
|
|
|
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_<...>;
|
|
|
|
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.
|
|
|
|
To unregister a device, use:
|
|
|
|
hid_destroy_device(hid);
|
|
|
|
Once hid_destroy_device() returns, HID core will no longer make use of any
|
|
driver callbacks.
|
|
|
|
2.2) hid_ll_driver operations
|
|
-----------------------------
|
|
|
|
The available HID callbacks are:
|
|
- int (*start) (struct hid_device *hdev)
|
|
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.
|
|
|
|
- void (*stop) (struct hid_device *hdev)
|
|
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.
|
|
Transport drivers are free to ignore it and deinitialize devices after they
|
|
destroyed them via hid_destroy_device().
|
|
|
|
- int (*open) (struct hid_device *hdev)
|
|
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.
|
|
|
|
- void (*close) (struct hid_device *hdev)
|
|
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).
|
|
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.
|
|
|
|
- int (*parse) (struct hid_device *hdev)
|
|
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().
|
|
|
|
- int (*power) (struct hid_device *hdev, int level)
|
|
Called by HID core to give PM hints to transport drivers. Usually this is
|
|
analogical to the ->open() and ->close() hints and redundant.
|
|
|
|
- void (*request) (struct hid_device *hdev, struct hid_report *report,
|
|
int reqtype)
|
|
Send an 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.
|
|
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.
|
|
|
|
- int (*wait) (struct hid_device *hdev)
|
|
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.
|
|
|
|
- int (*raw_request) (struct hid_device *hdev, unsigned char reportnum,
|
|
__u8 *buf, size_t count, unsigned char rtype,
|
|
int reqtype)
|
|
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.
|
|
|
|
- int (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len)
|
|
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!
|
|
|
|
- int (*idle) (struct hid_device *hdev, int report, int idle, int reqtype)
|
|
Perform SET/GET_IDLE request. Only used by USB-HID, do not implement!
|
|
|
|
2.3) Data Path
|
|
--------------
|
|
|
|
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.
|
|
|
|
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 <dh.herrmann@gmail.com>
|