This is a mandatory request (if the DEVICE contains Input or Feature reports) and shall be supported on both the HOST end and the DEVICE end. This request is primarily used for getting Feature Report from the DEVICE. This request is also useful at initialization time for absolute input items. It is NOT intended for polling the data from the device and the HOST shall leverage the input register for this functionality. The DEVICE shall ignore a GET_REPORT requests with the REPORT TYPE set to Output, as it is not used in this specification. HOST will utilize repeated start for this transaction. DEVICE may use I2C clock stretching per specification if critical. The protocol is optimized for Report <15. If a Report ID >= 15 is necessary, then the Report ID in the Low Byte must be set to ‘1111’ and a Third Byte is appended to the protocol. This Third Byte contains the entire/actual report ID. The value 1111 in the Low Byte’s Report ID is used as a sentinel value to indicate the need for the Report ID in the Third Byte. This mechanism optimizes the protocol for most reports (few devices need Report ID >=15) while still maintaining compatibility with other transports that allow Report IDs up to 255. The following is an illustration of the protocol between the HOST and the DEVICE for GET_REPORT, in situations where Report ID needs to be < 15. Figure : GET_REPORT Protocol Diagram (* Report ID < 15) The following is an illustration of the protocol between the HOST and the DEVICE for GET_REPORT, in situations where Report ID needs to be >= 15. Figure : GET_REPORT Protocol Diagram (*Report ID >= 15) SET_REPORT The SET_REPORT command is a specific request that the HOST may issue to the DEVICE at any time after initialization to set a singular report on the DEVICE. The DEVICE is responsible for accepting the value provided in the Data register and updating its state. A DEVICE must accept SET_REPORTS for all report types specified in the report descriptor.
This is a mandatory request (if the DEVICE contains Input or Feature reports) and shall be supported on both the HOST end and the DEVICE end. This request is primarily used for getting Feature Report from the DEVICE. This request is also useful at initialization time for absolute input items. It is NOT intended for polling the data from the device and the HOST shall leverage the input register for this functionality. The DEVICE shall ignore a GET_REPORT requests with the REPORT TYPE set to Output, as it is not used in this specification. HOST will utilize repeated start for this transaction. DEVICE may use I2C clock stretching per specification if critical. The protocol is optimized for Report <15. If a Report ID >= 15 is necessary, then the Report ID in the Low Byte must be set to ‘1111’ and a Third Byte is appended to the protocol. This Third Byte contains the entire/actual report ID. The value 1111 in the Low Byte’s Report ID is used as a sentinel value to indicate the need for the Report ID in the Third Byte. This mechanism optimizes the protocol for most reports (few devices need Report ID >=15) while still maintaining compatibility with other transports that allow Report IDs up to 255. The following is an illustration of the protocol between the HOST and the DEVICE for GET_REPORT, in situations where Report ID needs to be < 15. Figure : GET_REPORT Protocol Diagram (* Report ID < 15) The following is an illustration of the protocol between the HOST and the DEVICE for GET_REPORT, in situations where Report ID needs to be >= 15. Figure : GET_REPORT Protocol Diagram (*Report ID >= 15) SET_REPORT The SET_REPORT command is a specific request that the HOST may issue to the DEVICE at any time after initialization to set a singular report on the DEVICE. The DEVICE is responsible for accepting the value provided in the Data register and updating its state. A DEVICE must accept SET_REPORTS for all report types specified in the report descriptor.
hid-over-i2c-protocol-spec-v1-0.docx