Microsoft Windows CE 3.0  

Sample HID Class Driver

Important:
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: