-->
- Drivers Hid Global Usb Devices Pc Camera
- Drivers Hid Global Usb Devices Dongle
- Drivers Hid Global USB Devices
Human Interface Devices (HID) is a device class definition to replace PS/2-style connectors with a generic USB driver to support HID devices such as keyboards, mice, game controllers, etc. Prior to HID, devices could only utilize strictly-defined protocols for mice and keyboards. Hardware innovation required either overloading data in an existing protocol or creating non-standard hardware with its own specialized driver. HID provided support for these 'boot mode' devices while adding support for hardware innovation through extensible, standardized and easily-programmable interfaces.
Drivers Hid Global Usb Devices Pc Camera
HID devices today include a broad range of devices such as alphanumeric displays, bar code readers, volume controls on speakers/headsets, auxiliary displays, sensors and many others. Many hardware vendors also use HID for their proprietary devices.
HID began with USB but was designed to be bus-agnostic. It was designed for low latency, low bandwidth devices but with flexibility to specify the rate in the underlying transport. The specification for HID over USB was ratified by the USB-IF in 1996 and support over additional transports followed soon after. Details on currently supported transports can be found in HID Transports Supported in Windows. 3rd-party, vendor-specific transports are also allowed via custom transport drivers.
Windows provides a HID parser for use by drivers and applications via APIs (HidP.) that can be used to discover the types of usages supported by a device, determine the state of such usages in a Report, or to build a Report to change the state of a usage in the device. These are the HID parser APIs. In the example for this article, the driver handoff is to the HID-class driver. If the descriptors don't specify a class, then the device's VID (vendor ID) and PID (product ID), gathered from the descriptors, identify an appropriate driver for the USB device. In a properly designed USB HID device, you need not worry about the driver process. Apple supplies drivers and services for all standard hardware devices and communication protocols, including USB, Thunderbolt, Peripheral Component Interconnect (PCI), and more. Apple also provides drivers and services for the most common human interface device (HID) types, including mice and keyboards.
HID Concepts
HID consists of two fundamental concepts, a Report Descriptor, and Reports. Reports are the actual data that is exchanged between a device and a software client. The Report Descriptor describes the format and meaning the data that the device supports.
Reports
Applications and HID devices exchange data through Reports. There are three Report types: Input Reports, Output Reports, and Feature Reports.
Drivers Hid Global Usb Devices Dongle
| Report Type | Description |
|---|---|
| Input Report | Data sent from the HID device to the application, typically when the state of a control changes. |
| Output Report | Data sent from the application to the HID device, for example to the LEDs on a keyboard. |
| Feature Report | Data that can be manually read and/or written, and are typically related to configuration information. |
Each Top Level Collection defined in a Report Descriptor can contain zero (0) or more reports of each type.
Usage Tables
The USB-IF working group publishes HID Usage Tables that are part of the Report Descriptors that describe what HID devices are allowed to do. These HID Usage Tables contain a list with descriptions of Usages, which describe the intended meaning and use of a particular item described in the Report Descriptor. For example, a Usage is defined for the left button of a mouse. The Report Descriptor can define where in a Report an application can find the current state of the mouse's left button. The Usage Tables are broken up into several name spaces, called Usage Pages. Each Usage Page describes a set of related Usages to help organize the document. The combination of a Usage Page and Usage define the Usage ID that uniquely identifies a specific Usage in the Usage Tables.
See also
USB-IF HID Specifications.
-->This topic describes best practices about implementing the remote wakeup capability in a client driver.
USB devices that can respond to external wake signals while suspended are said to have a remote wakeup capability. Examples of devices that have a remote wakeup capability are mice, keyboards, USB hubs, modems (wake on ring), NICs, wake on cable insertion. All of these devices are capable of producing remote wake signaling. Devices that are not capable of generating remote wake signaling include video cameras, mass storage devices, audio devices, and printers.
Drivers for devices that support remote wakeup signaling must issue an IRP_MN_WAIT_WAKE IRP, also known as a wait wake IRP, to arm the device for remote wakeup. The wait wake mechanism is described in the section Supporting Devices That Have Wake-Up Capabilities.
Drivers Hid Global USB Devices
When Does the System Enable Remote Wakeup on a USB Leaf Device?
In USB terminology, a USB device is enabled for remote wakeup when its DEVICE_REMOTE_WAKEUP feature is set. The USB specification specifies that host software must set the remote wakeup feature on a device 'only just prior' to putting the device to sleep.
For this reason, the USB stack does not set the DEVICE_REMOTE_WAKEUP feature on a device after receiving a wait wake IRP for the device. Instead, it waits until it receives a IRP_MN_SET_POWER request to change the WDM device state of the device to D1/D2. Under most circumstances, when the USB stack receives this request, it both sets the remote wakeup feature on the device and puts the device to sleep by suspending the device's upstream port. When you design and debug your driver, you should keep in mind that there is a loose relationship between arming a USB device for wakeup in software, by means of a wait wake IRP, and arming the device for wakeup in hardware by setting the remote wakeup feature.
The USB stack does not enable the device for remote wakeup when it receives a request to change the device to a sleep state of D3, because according to the WDM power model, devices in D3 cannot wake the system.
Why Does Attaching or Detaching My Device Produce a Different Wakeup Behavior in Windows XP and Windows Vista and later versions of Windows?
Another unique aspect of the USB implementation of the WDM power mode regards the arming of USB hubs for remote wakeup. In Microsoft Windows XP all hub devices between host controller and the USB device are armed for wakeup whenever the USB device is armed for wakeup. This produces the surprising consequence that when sleeping devices are detached they will wake up the system.
When Does the System Enable Remote Wakeup on a USB Leaf Device?
In USB terminology, a USB device is enabled for remote wakeup when its DEVICE_REMOTE_WAKEUP feature is set. The USB specification specifies that host software must set the remote wakeup feature on a device 'only just prior' to putting the device to sleep.
For this reason, the USB stack does not set the DEVICE_REMOTE_WAKEUP feature on a device after receiving a wait wake IRP for the device. Instead, it waits until it receives a IRP_MN_SET_POWER request to change the WDM device state of the device to D1/D2. Under most circumstances, when the USB stack receives this request, it both sets the remote wakeup feature on the device and puts the device to sleep by suspending the device's upstream port. When you design and debug your driver, you should keep in mind that there is a loose relationship between arming a USB device for wakeup in software, by means of a wait wake IRP, and arming the device for wakeup in hardware by setting the remote wakeup feature.
The USB stack does not enable the device for remote wakeup when it receives a request to change the device to a sleep state of D3, because according to the WDM power model, devices in D3 cannot wake the system.
Why Does Attaching or Detaching My Device Produce a Different Wakeup Behavior in Windows XP and Windows Vista and later versions of Windows?
Another unique aspect of the USB implementation of the WDM power mode regards the arming of USB hubs for remote wakeup. In Microsoft Windows XP all hub devices between host controller and the USB device are armed for wakeup whenever the USB device is armed for wakeup. This produces the surprising consequence that when sleeping devices are detached they will wake up the system.
In Windows Vista and later versions of Windows, if a USB leaf device on the bus is armed for wake, the USB stack will also arm the USB host controller for wake, but it will not necessarily arm any of the USB hubs upstream of the device. The USB hub driver arms a hub for remote wakeup only if the USB stack is configured to wake up the system on attach and detach (plug/unplug) events.
Note UHCI (Universal Host Controller Interface) USB host controllers do not distinguish between remote wake signaling and connect change events on root hub ports. This means the system will always wake from a low system power state if a USB device is connected to or disconnected from a root hub port, if there is at least one device behind the UHCI controller that is armed for wake.
Related topics
