Lines Matching refs:as

12 The HID subsystem is designed as a bus. Any I/O subsystem may provide HID
48 Everything below "HID Core" is simplified in this graph as it is only of
67 HID core will operate a device as long as it is registered regardless of any
81 driver in whatever way they like. They might just be the same as asynchronous
92 will describe them as two bi-directional channels as they have several
129    on the intr channel as this channel is asynchronous.
131 INPUT and OUTPUT reports can be sent as pure data reports on the intr channel.
133 this is rarely done as OUTPUT reports are normally quite scarce. But devices are
141  - GET_REPORT: A GET_REPORT request has a report ID as payload and is sent
143    requested report ID on the ctrl channel as a synchronous acknowledgement.
145    is enforced by HID core as several transport drivers don't allow multiple
147    Note that data reports which are sent as answer to a GET_REPORT request are
148    not handled as generic device events. That is, if a device does not operate
156    return the current report state of the device. However, OUTPUT reports as
159  - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is
162    INPUT reports as payload might be blocked by the underlying transport driver
167    Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This
168    restriction is enforced by HID core as some transport drivers do not support
284    Same as ->request() but provides the report as raw buffer. This request shall
292    must not cause SET_REPORT calls! This must be implemented as asynchronous