windows-xp/Source/XPSP1/NT/multimedia/directx/dinput/dx8/dll/hidsys.htm

<HTML>
<HEAD>
<TITLE>Designing HID System Devices for Windows and DirectInput</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#000000 VLINK=#808080 ALINK=#000000>

<H2>Designing HID System Devices for Windows and DirectInput</H2>

<ADDRESS>
Raymond Chen<br>
Microsoft Corporation<br>
14 November 1997
</ADDRESS>

<h3>Abstract</h3>

<p>
Recommendations for designing a mouse or keyboard
compliant with the Human Interface Devices (HID)
firmware specification are presented.
Following these recommendations will ensure that
the device can be used both by standard Windows applications
and DirectInput applications.

<h3>Overview and Definitions</h3>

<p>
In this document, when behavior or requirements are attributed
to "Windows", the behavior or requirements apply to the
HID mapping layer, which transforms HID reports into input
events compatible with earlier non-HID devices,
thereby allowing HID-compliant mice and keyboards to be used
as normal Windows input devices.
On Windows 98, the components that perform these transformations
are called MouHID (HID mouse mapping layer) and
KbdHID (HID keyboard mapping layer).

<p>
When behavior or requirements are attributed to "DirectInput",
the behavior or requirements apply to the portion of the
Microsoft DirectX API commonly known as "DirectInput".
DirectInput bypasses the Windows messaging subsystem and
communicates directly with device drivers.  For HID-compliant
devices, DirectInput communicates directly with the HID stack.

<h3>Mouse Requirements</h3>

<p>
For Windows and DirectInput
DirectInput to recognize a HID-compliant device
as a mouse,
it must declare its top-level collection as belonging to
the Generic Desktop Page (0x01)
and deploy usage Mouse (0x02) or Pointer (0x01).

<p>
The device must report its X and Y coordinates under the
Generic Desktop Page (0x01) as usages X (0x30) and Y (0x31),
respectively.
Windows requires that the X and Y usages both be absolute
or both be relative.
<i>Furthermore, Windows also requires that they be the
first capabilities in the report descriptor.
<b>This is actually a bug in MouHID B#56937 - MouHID must
check the absolute/relative capabilities on the X and Y axes
specifically, not on a randomly-selected capability.
KenRay confirms that HidParse enumerates capabilities in a
random order.</b>
Consequently, if a HID-compliant device exposes inputs
in addition to the X and Y axes, it must make sure to list
the other inputs after the X and Y axes in the report descriptor.
</i>

<p>
Both Windows and DirectInput require that
if the device contains a wheel,
the wheel must be exposed as a relative control on the
Generic Desktop Page (0x01) as usage Wheel (0x38).
When the wheel is rotated away from the user one unit,
the value of the wheel control should increase by one.

<p>
Windows requires that the buttons on the device all reside
on the Generic Button Page (0x09), consecutively numbered,
starting with <i>unity</i> (not zero).

<h3>Keyboard Requirements</h3>

<p>
For Windows and DirectInput
DirectInput to recognize a HID-compliant device
as a keyboard,
it must declare its top-level collection as belonging to
the Generic Desktop Page (0x01)
and deploy usage Keyboard (0x07).
Windows also recognizes usage System Controls (0x80) as a keyboard.

<h3>References</h3>

<p>
<cite>
<a href=http://www.usb.org/>Universal Serial Bus</a>
HID Usage Tables</cite>, Version 1.0,
USB Implementers Forum.

<p>
<cite>
<a href=http://www.microsoft.com/directx/resources/dx5sdk.htm>
DirectX 5.0 SDK</a>
</cite>, Microsoft Corporation.

</BODY>
</HTML>