31.08.2013 Views

HID Sensor Usage Tables - USB.org

HID Sensor Usage Tables - USB.org

HID Sensor Usage Tables - USB.org

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

104 <strong>HID</strong> <strong>Sensor</strong> <strong>Usage</strong>s<br />

o Performing a <strong>HID</strong> Get Input Report request to retrieve a single “table row” consisting of<br />

the GUID_OR_PROPERTYKEY struct;<br />

o After each <strong>HID</strong> Get Input Report request, the sensor firmware automatically increments<br />

the <strong>HID</strong>_USAGE_SENSOR_DATA_ENUMERATOR_TABLE_ROW_INDEX.<br />

Once this operation is complete, the platform driver will now know:<br />

The top level collection number (from 2 to n) of every sensor represented by the device;<br />

The <strong>Sensor</strong> Category and <strong>Sensor</strong> Type of each sensor;<br />

The <strong>Sensor</strong> Events emitted by each sensor;<br />

All of the Data Fields reported by each sensor; and for each of those Data Fields, its Report ID,<br />

packing position, data type, size, unit of measure, and so on;<br />

All of the Properties supported by each sensor; and for each of those Properties, its Report ID,<br />

packing position, data type, size, unit of measure, and so on.<br />

When the platform driver wishes to interpret any Data Field or Property, it has all the information it needs<br />

without requiring any of the identifying information to be “inline” in the Reports themselves. This frees up<br />

the entire packet (other than the single byte for the Report ID) for holding the data values.<br />

Here is an example of a <strong>HID</strong> Report Descriptor illustrating this concept:<br />

// Complete <strong>HID</strong> report descriptor<br />

const unsigned char enum_sensor_report_descriptor[] = {<br />

<strong>HID</strong>_USAGE_PAGE_SENSOR,<br />

<strong>HID</strong>_USAGE_SENSOR_TYPE_COLLECTION<br />

<strong>HID</strong>_COLLECTION(Application),<br />

};<br />

// Global items<br />

<strong>HID</strong>_REPORT_SIZE(8),<br />

<strong>HID</strong>_LOGICAL_MIN_8(0),<br />

<strong>HID</strong>_LOGICAL_MAX_8(255),<br />

// Report ID 0x08: an Input Report with 37 bytes of Data Fields<br />

<strong>HID</strong>_REPORT_ID(0x08),<br />

<strong>HID</strong>_USAGE_SENSOR_DATA_GENERIC_DATAFIELD,<br />

<strong>HID</strong>_REPORT_COUNT(37),<br />

<strong>HID</strong>_INPUT(Const_Arr_Abs),<br />

// Report ID 0x09: a Feature Report with 63 bytes of Read-Only Properties<br />

<strong>HID</strong>_REPORT_ID(0x09),<br />

<strong>HID</strong>_USAGE_SENSOR_DATA_GENERIC_PROPERTY,<br />

<strong>HID</strong>_REPORT_COUNT(63),<br />

<strong>HID</strong>_FEATURE(Const_Arr_Abs),<br />

// Report ID 0x0a: a Feature Report with 42 bytes of Read/Write Properties<br />

<strong>HID</strong>_REPORT_ID(0x0a),<br />

<strong>HID</strong>_USAGE_SENSOR_DATA_GENERIC_PROPERTY,<br />

<strong>HID</strong>_REPORT_COUNT(42),<br />

<strong>HID</strong>_FEATURE(Data_Arr_Abs),<br />

<strong>HID</strong>_END_COLLECTION<br />

Note from the above that the contents of the Input Reports and Feature Reports are completely opaque.<br />

The Generic Enumerator table rows must be consulted to make any sense out of the data values in the<br />

Reports. The advantage of this approach is that it allows complete “run time” flexibility in the semantics of<br />

the data being transferred.<br />

4.3 Illustrative <strong>Sensor</strong> Report Descriptors<br />

4.3.1 Biometric: Human Presence<br />

// Complete <strong>HID</strong> report descriptor<br />

//Human Presence<br />

const unsigned char pres_report_descriptor[] = {<br />

<strong>HID</strong>_USAGE_PAGE_SENSOR,<br />

<strong>HID</strong>_USAGE_SENSOR_TYPE_BIOMETRIC_PRESENCE,<br />

<strong>HID</strong>_COLLECTION(Physical),

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!