Windows.Devices.HumanInterfaceDevice Namespace
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
This namespace gives your UWP app access to devices that support the Human Interface Device (HID) protocol.
Device Support
This namespace supports most HIDs. However, it does not provide access to top-level application collections (TLCs) represented by the following usages.
Inaccessible Usages.
UsagePage | UsageIds |
---|---|
HID_USAGE_PAGE_UNDEFINED (0x00 ) |
All |
HID_USAGE_PAGE_GENERIC (0x01 ) |
HID_USAGE_GENERIC_MOUSE (0x02 )HID_USAGE_GENERIC_KEYBOARD (0x06 )HID_USAGE_GENERIC_KEYPAD (0x07 )HID_USAGE_GENERIC_SYSTEM_CTL (0x80 ) |
HID_USAGE_PAGE_KEYBOARD (0x07 ) |
All |
HID_USAGE_PAGE_CONSUMER (0x0C ) |
All |
HID_USAGE_PAGE_DIGITIZER (0x0D ) |
All |
HID_USAGE_PAGE_SENSOR (0x20 ) |
All |
HID_USAGE_PAGE_LIGHTING_ILLUMINATION (0x59 ) |
HID_USAGE_LAMPARRAY (0x01 ) |
- Keyboard and mouse devices are system reserved devices
- LampArray HIDs can be enumerated with HidDevice.GetDeviceSelector but must be instantiated with LampArray.FromIdAsync
- Sensor HIDs can be enumerated with HidDevice.GetDeviceSelector but must be instantiated with their respective Windows.Devices.Sensors device (e.g. LightSensor.FromIdAsync)
Human Interface Device Capabilities
A UWP app that accesses a HID must include specific device capability data in the capabilities node of its manifest. This data identifies the device and its purpose (or function). Note that some devices may have multiple functions.
Since Windows 10, version 1809 (October 2018 Update)
- <DeviceCapability>: The Name attribute must be
humanInterfaceDevice
.
<DeviceCapability Name="humanInterfaceDevice"/>
If targeting a HID telephony device (UsagePage==0x0B
), the additional capability hidTelephony
must also be specified.
<DeviceCapability Name="humanInterfaceDevice"/>
<DeviceCapability Name="hidTelephony"/>
Before Windows 10, version 1809 (October 2018 Update)
Since 1809, the VendorId/ProductId and function-type no longer need to be specified and will be ignored on newer systems. If targeting systems before 1809, then see below.
<DeviceCapability>: The Name attribute must be
humanInterfaceDevice
.<Device>: The Id attribute must specify the device identifier. This element may specify a combination Vendor Id (vid) and Product Id (pid); or, it may specify a generic string
any
. In addition, theDevice Id
may contain an optional provider string ofusb
orbluetooth
.- <Function>: The Type attribute specifies the device function. This element contains one or more HID usage values. These values consist of a
UsagePage
and an optionalUsageId
, each of which are 16-bit hexadecimal values.
- <Function>: The Type attribute specifies the device function. This element contains one or more HID usage values. These values consist of a
In the following vendor-defined usage data, the device is identified by the Vendor Id and Product Id combination.
<DeviceCapability Name="humaninterfacedevice">
<Device Id="vidpid:0A81 0701">
<Function Type="usage:ffa0 0001"/>
</Device>
</DeviceCapability>
The following is identical to the first with the exception of the additional provider string usb
in the Device Id
element.
<DeviceCapability Name="humaninterfacedevice">
<Device Id="vidpid:0A81 0701 usb">
<Function Type="usage:ffa0 0001"/>
</Device>
</DeviceCapability>
In the following gaming-device data there is no Vendor Id and Product Id.
<!-- Any gamepad device -->
<DeviceCapability Name="humaninterfacedevice">
<Device Id="any">
<Function Type="usage:0005 *"/>
</Device>
</DeviceCapability>
In the following joystick and game pad data there is no Vendor Id and Product Id
<!-- Any generic gaming device -->
<DeviceCapability Name="humaninterfacedevice">
<Device Id="any">
<Function Type="usage:0004 *"/>
<Function Type="usage:0005 *"/>
</Device>
</DeviceCapability>
Troubleshooting
- Verify the HID capability (
humanInterfaceDevice
) is in the application manifest. If a telephony device, ensure thehidTelephony
capability is also included. - Verify the user has granted permission for the application to utilize HIDs.
- Verify the device type is not one designated as inaccessible.
- Inaccessible HIDs may still be enumerated by DeviceInformation.FindAllAsync(), but cannot be opened by HumanInterfaceDevice.FromIdAsync(). Attemping to open such a device will either throw an exception or return
null
.
- Inaccessible HIDs may still be enumerated by DeviceInformation.FindAllAsync(), but cannot be opened by HumanInterfaceDevice.FromIdAsync(). Attemping to open such a device will either throw an exception or return
- Machine-internal devices (
DEVPKEY_Device_InLocalMachineContainer == TRUE
) are generally not accessible unless running on a SKU with embedded mode andlowLevelDevices
capability. - Devices with stacks that contain upper/lower filter drivers are generally not accessible. These are sometimes added by 3rd parties to enable additional functionality for custom hardware.
- Device restriction is partially determined by
hidclass.sys
during device enumeration, which may set the device interface propertyDEVPKEY_DeviceInterface_Restricted
toTRUE
on the HID Device InterfaceGUID_DEVINTERFACE_HID
based on the presence of device/class filters. - The presence of device UpperFilter/LowerFilter drivers can be determined using DeviceManager by looking for
UpperFilters
andLowerFilters
properties. - The presence of HID class UpperFilter/LowerFilter drivers can be determined using DeviceManager by looking for
Class upper filters
andClass lower filters
properties. - Device Interface properties can be inspected by calling
CM_Get_Device_Interface_Property
wherepszDeviceInterface
is the same string as would be passed to FromIdAsync.
- Device restriction is partially determined by
- These restrictions can be bypassed when making a custom device by working with the driver-developer to create a Hardware Support App
Classes
HidBooleanControl |
Represents a simple Boolean control on a HID device that returns on/off values. An example would be the LED light on a keyboard. |
HidBooleanControlDescription |
Describes a Boolean control for a given HID device. |
HidCollection |
Retrieves the collection information for a group of related controls. The HID protocol uses collections to group a set of controls that are similar to one another, or, are related by physical or operational proximity. |
HidDevice |
Represents a top-level collection and the corresponding device. |
HidFeatureReport |
Represents a HID Feature Report. Feature reports are issued by both the device and the host. Devices issue feature reports to describe their capabilities and default settings to a host. Hosts issue feature reports to make requests of the device. |
HidInputReport |
Represents a HID Input Report. Devices issue input reports to describe state changes, user-input, and other device-specific data. For example, a HID keyboard device would use an input report to signal a key press. A HID presence-sensor would use an input report to signal a presence detection event. |
HidInputReportReceivedEventArgs |
Represents the arguments which the HID API sends as part of an input-report event. |
HidNumericControl |
Represents a numeric control on a HID device that returns a range of values. An example would be the volume control on a speaker. |
HidNumericControlDescription |
Describes a numeric control for a given HID device. |
HidOutputReport |
Represents a HID Output Report. Hosts issue output reports to request changes on the device. For example, a host could issue a request to a keyboard to turn an LED on or off. |
Enums
HidCollectionType |
Identifies the relationship that defines a grouping of controls on the device. Collections are a way to group a set of controls that are similar to one another; or, are related by physical, or, operational proximity. |
HidReportType |
Specifies a HID report type. |