Share via

Windows.Devices.HumanInterfaceDevice Namespace

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

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 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, the Device Id may contain an optional provider string of usb or bluetooth.

      • <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 optional UsageId, each of which are 16-bit hexadecimal values.

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"/>

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"/>

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 *"/>

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 *"/>


  • Verify the HID capability (humanInterfaceDevice) is in the application manifest. If a telephony device, ensure the hidTelephony 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.
  • Machine-internal devices (DEVPKEY_Device_InLocalMachineContainer == TRUE) are generally not accessible unless running on a SKU with embedded mode and lowLevelDevices 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 property DEVPKEY_DeviceInterface_Restricted to TRUE on the HID Device Interface GUID_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 and LowerFilters properties.
    • The presence of HID class UpperFilter/LowerFilter drivers can be determined using DeviceManager by looking for Class upper filters and Class lower filters properties.
    • Device Interface properties can be inspected by calling CM_Get_Device_Interface_Property where pszDeviceInterface is the same string as would be passed to FromIdAsync.
  • These restrictions can be bypassed when making a custom device by working with the driver-developer to create a Hardware Support App



Represents a simple Boolean control on a HID device that returns on/off values. An example would be the LED light on a keyboard.


Describes a Boolean control for a given HID device.


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.


Represents a top-level collection and the corresponding device.


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.


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.


Represents the arguments which the HID API sends as part of an input-report event.


Represents a numeric control on a HID device that returns a range of values. An example would be the volume control on a speaker.


Describes a numeric control for a given HID device.


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.



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.


Specifies a HID report type.

See also