|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Microsoft provides a sample class driver for Human Interface class devices. This USB device driver supports the following Human Interface class devices: joysticks, gamepads, mice, trackballs, and keyboards. In order to present applications with a consistent method of accessing those devices, the HID class driver uses the Microsoft DirectInput API. It uses the stream interface functions to interact with the DirectInput (DI) subsystem.
In the sample, the registry keys are configured to load the drivers automatically; plugging in an HID class device such as a mouse or keyboard loads the HID class driver.
The following series of actions takes place when a user connects an HID device such as a mouse or keyboard to a Windows CE-based platform that contains the HID class driver. After the HID class driver is loaded and the USBD module calls the driver's USBDeviceAttachfunction, the driver calls an initialize function that opens a pipe to the HID device's interrupt endpoint. It also starts a worker thread to handle interrupts. This thread enters a loop in which it submits interrupt transfers by calling the IssueInterruptTransferfunction. After the transfer completes, the driver retrieves the event data from the function's lpvBufferparameter. It then creates an appropriate mouse or keyboard event to submit to the Windows CE input system and the DI subsystem.
The HID class driver submits input to both DI and the Windows CE input system for two reasons. One is so that DI is not required to be present in a Windows CE-based platform just to use the HID class driver. The other is that if an application that is using DI to access the mouse or keyboard fails or stops responding, the use of those devices is still available to other applications. The sample HID class driver presents itself to the DirectInput subsystem as a stream interface device, with the special device file name "HID1:". The device filename prefix, "HID", is currently mandatory. Future versions of Windows CE may allow OEMs to specify this prefix via a registry key.
The DirectInput subsystem in Windows CE uses I/O control codes to request various actions from the HID class driver. The following table shows the eight I/O control codes that the HID class driver must support in its IOControlfunction:
|I/O control code||Description|
|IOCTL_HID_ACQUIRE||Notifies the HID class driver that the DirectInput subsystem no longer wants to receive events connected to a handle that was previously obtained through use of the IOCTL_HID_SET_FORMAT control code.|
|IOCTL_HID_ATTACH||Notifies the HID class driver that an application needs to use a device.|
|IOCTL_HID_ENUM_DEVICES||Returns a list of devices that the HID class driver is currently managing.|
|IOCTL_HID_ENUM_OBJECTS||Returns the number of input sources, such as buttons, on the device.|
|IOCTL_HID_GET_INST_DATA||Returns data from the device to the DirectInput subsystem.|
|IOCTL_HID_POLL||Requests that the HID class driver poll the device to get the device's status.|
|IOCTL_HID_SET_FORMAT||Sets the format of data that the HID class driver returns for a device to the DirectInput subsystem, and acquires the device for use by an application.|
|IOCTL_HID_TRANSFER_EVENT||Registers an event handle that the HID class driver can use to notify the DirectInput subsystem when the device generates data.|
The implementation of the DirectInput subsystem for Windows CE is a subset of the full DirectInput API that is defined for desktop versions of Windows. The following differences between these implementations affect the HID class driver:
The sample HID class driver is available as part of the Microsoft Windows CE Platform Builder 3.0, in the directory \WinCE\public\common\oak\drivers\usb\class\hid.
Last updated on Tuesday, July 13, 2004