Skip to content

USB Interfaces

Summary
  • A USB device doesn't talk to the host as one blob of functionality — it advertises itself through a fixed descriptor hierarchy: Device → Configuration → Interface → Endpoint.1
  • An interface is the unit of function. One physical device (a webcam, a gaming mouse, a phone) can expose several interfaces at once, each independently claimed by its own driver.
  • Composite devices — anything with more than one interface — are split apart by a generic parent driver (usbccgp.sys on Windows) into separate child devices, one per interface, each of which then gets its own class driver.

Think of a USB interface as:

"A single department inside a larger building. The building (the device) has one street address, but each department (interface) has its own staff (driver), its own mailroom (endpoints), and does its own job — HR doesn't answer Shipping's phone."

The Descriptor Hierarchy

Every USB device reports itself to the host in a strict, nested structure, read in this order during enumeration:1

Descriptor Scope Typical Contents
Device Descriptor The whole device idVendor, idProduct, bcdUSB, bDeviceClass, bNumConfigurations
Configuration Descriptor One configuration (usually just one) bNumInterfaces, bmAttributes (power), MaxPower
Interface Descriptor One interface within that configuration bInterfaceClass/SubClass/Protocol, bNumEndpoints
Class-Specific Descriptor Extends an interface with class detail e.g., a HID Descriptor carrying bcdHID and Report Descriptor length
Endpoint Descriptor One endpoint within an interface direction, transfer type, wMaxPacketSize, bInterval

Table 1. USB Descriptor Hierarchy

Descriptors are static; the report descriptor is dynamic

Most descriptors above are fixed-format binary structures the host parses directly. HID interfaces are the exception: they carry an extra Report Descriptor, a small byte-code program describing exactly what each bit in an input/output report means — buttons, axes, dials, whatever the device needs, without the USB spec having to hard-code every possible input type.2

What Defines an Interface

Three fields on the Interface Descriptor — read together — tell the host which driver to load, with no user interaction required:1

Interface Descriptor — class-matching triad
bInterfaceClass:     0x03  # (1)!
bInterfaceSubClass:  0x01  # (2)!
bInterfaceProtocol:  0x02  # (3)!
  1. bInterfaceClass — The broad category of function (see the class table below). 0x03 = HID.
  2. bInterfaceSubClass — A narrower refinement within that class. For HID, 0x01 specifically flags a Boot Interface.
  3. bInterfaceProtocol — The most specific match. Only meaningful alongside a Boot Interface SubClass — 0x01 = Keyboard, 0x02 = Mouse.

Windows (and every other OS) matches this triad against installed driver INF files to decide what loads — this is exactly the mechanism behind the Hardware IDs lists you'll see in any device driver report.

Common Interface Classes

Class Code Name Typical Device
0x01 Audio Speakers, microphones, headsets
0x02 CDC (Communications) USB modems, virtual serial ports
0x03 HID (Human Interface Device) Keyboards, mice, gamepads
0x08 Mass Storage Flash drives, external SSDs
0x09 Hub USB hubs themselves
0x0E Video (UVC) Webcams
0xE0 Wireless Controller Bluetooth dongles
0xFF Vendor-Specific Proprietary, driver supplied by the manufacturer

Table 2. Selected USB Interface Class Codes

Endpoints & Transfer Types

Every interface communicates through one or more endpoints — unidirectional data channels, each using one of four transfer types with very different guarantees:3

Transfer Type Guarantee Latency Typical Use
Control Reliable, guaranteed delivery N/A (on-demand) Setup, configuration, endpoint 0 on every device
Interrupt Reliable, guaranteed bandwidth & polling interval Low, fixed (e.g. every 1 ms) Keyboards, mice, gamepads
Bulk Reliable, but best-effort timing Variable, can be delayed Flash drives, printers
Isochronous Not guaranteed delivery — timing over correctness Fixed, real-time Audio/video streaming

Table 3. USB Transfer Types

Why mice use Interrupt, not Bulk

A dropped mouse-movement packet is invisible to a human; a late one causes visible input lag. Interrupt transfers trade a small, fixed bandwidth reservation for a hard guarantee on when the host will next poll the device — exactly what pointing devices need, and exactly why HID mice negotiate a bInterval of 1 ms rather than using Bulk transfers.

Composite Devices & the Driver Split

A device with more than one interface is a composite device. On Windows, a generic parent driver (usbccgp.sys, the USB Common Class Generic Parent driver) claims the whole device first, then spins up one child device node per interface — each of which is independently matched against its own class driver, using only that interface's own class triad and Hardware IDs.4

One physical device → multiple driver-bound nodes
Physical Device:      "G502 HERO Gaming Mouse"
Interface 0 (MI_00):  HID Boot Mouse  → hidusb.sys → mouhid.sys
Interface 1 (MI_01):  Extended HID    → hidusb.sys → (vendor software)

The MI_00 / MI_01 suffix you'll see throughout Hardware IDs on a composite device is exactly this: Multi-Interface index, tying each split-off child node back to a specific interface on the original Configuration Descriptor.

Worked Example: Logitech G502 HERO Gaming Mouse

About this example

Everything below is a real, annotated USBTreeView-style dump of one physical USB mouse, reorganized to show how the concepts above map onto an actual device. As with any report like this, personally identifiable / machine-specific identifiers (serial numbers, container IDs, full device paths, driver instance keys) have been replaced with [redacted]. Vendor/product IDs, descriptor values, and protocol data are left intact, since they're publicly documented by the USB-IF and the manufacturer, not unique to this specific unit.

Device Descriptor Summary

Vendor ID:                0x046D                            # (1)!
Product ID:               0xC08B                            # (2)!
Manufacturer String:      "Logitech"                        # (3)!
Product String:           "G502 HERO Gaming Mouse"          # (4)!
Serial:                   "[redacted]"                      # (5)!
USB Version:              "2.0 (12 Mbit/s FullSpeed only)"  # (6)!
Port Maximum Speed:       High-Speed                        # (7)!
Device Maximum Speed:     Full-Speed                        # (8)!
Device Connection Speed:  Full-Speed                        # (9)!
Self Powered:             no                                # (10)!
Demanded Current:         300 mA                            # (11)!
Used Endpoints:           3                                 # (12)!
  1. Vendor ID — USB-IF assigned identifier for Logitech Inc. Fixed across every Logitech USB device; public information.
  2. Product ID — Vendor-assigned identifier specific to the G502 HERO model. Together with the Vendor ID it identifies the product, not the individual unit.
  3. Manufacturer String — Human-readable manufacturer name pulled from String Descriptor 1.
  4. Product String — Human-readable product name pulled from String Descriptor 2.
  5. Serial — Unique per-unit serial number. Redacted — can fingerprint or track a specific physical device.
  6. USB Version — The bcdUSB value the device reports (2.0); it actually negotiates only Full-Speed (12 Mbit/s), not High-Speed (480 Mbit/s).
  7. Port Maximum Speed — The port's own top capability; a downstream companion port handles SuperSpeed traffic separately.
  8. Device Maximum Speed — The fastest speed class the device itself can negotiate, regardless of port capability.
  9. Device Connection Speed — The speed actually negotiated — matches the device's ceiling since the port outpaces it.
  10. Self Powered — Whether the device supplies its own power. no = fully bus-powered.
  11. Demanded Current — Bus power requested during enumeration, in milliamps.
  12. Used Endpoints — Active endpoints in use: control endpoint 0 plus the two interrupt IN endpoints below.

Port & Topology

Connection Status:       0x01          # (1)!
Port Chain:              1-1-1         # (2)!
IsUserConnectable:       yes           # (3)!
PortIsDebugCapable:      no            # (4)!
PortHasMultiCompanions:  no            # (5)!
PortConnectorIsTypeC:    no            # (6)!
CompanionHubSymLnk:      "[redacted]"  # (7)!
CompanionPortChain:      1-13-1        # (8)!
  1. Connection Status — 0x01 = currently connected and enumerated.
  2. Port Chain — Hub/port path from the root hub to this device.
  3. IsUserConnectable — Whether this is a user-accessible plug/unplug port.
  4. PortIsDebugCapable — Whether the port supports USB kernel debugging. Not applicable here.
  5. PortHasMultiCompanions — Whether the port shares multiple companion controllers. no = single companion relationship.
  6. PortConnectorIsTypeC — Physical connector type. no = legacy USB-A.
  7. CompanionHubSymLnk — Windows symbolic link to the companion SuperSpeed hub instance. Redacted — embeds a machine-specific instance path.
  8. CompanionPortChain — Equivalent port chain on the companion (SuperSpeed-capable) controller.

Device Information (Composite Parent Node)

Friendly Name:            "G502 HERO"                                             # (1)!
Device Description:       "G502 HERO"                                             # (2)!
BusReported Device Desc:  "G502 HERO Gaming Mouse"                                # (3)!
Device Path:              "[redacted]"                                            # (4)!
Kernel Name:              "\Device\USBPDO-8"                                      # (5)!
Device ID:                "[redacted]"                                            # (6)!
Hardware IDs:             "USB\VID_046D&PID_C08B&REV_6900 USB\VID_046D&PID_C08B"  # (7)!
Driver KeyName:           "[redacted]"                                            # (8)!
Driver:                   "\SystemRoot\System32\drivers\usbccgp.sys"              # (9)!
Driver Inf:               "C:\WINDOWS\inf\oem189.inf"                             # (10)!
Class:                    USB                                                     # (11)!
Service:                  usbccgp                                                 # (12)!
Location Info:            "Port_#0001.Hub_#0003"                                  # (13)!
Container ID:             "[redacted]"                                            # (14)!
Capabilities:             0x94                                                    # (15)!
Status:                   0x0180400A                                              # (16)!
Lower Filters:            "vhf, logi_lamparray"                                   # (17)!
First Install Date:       "2026-08-04"                                            # (18)!
Last Arrival Date:        "2026-08-13"                                            # (19)!
Power State:              D0                                                      # (20)!
  1. Friendly Name — Short display name Windows shows in Device Manager and elsewhere.
  2. Device Description — Descriptive text tied to the driver's INF for this hardware ID.
  3. BusReported Device Desc — The product string the device itself reports over USB, independent of any driver.
  4. Device Path — Full Windows device interface path, which embeds the serial number. Redacted.
  5. Kernel Name — Internal PDO kernel object name — session-specific, not unique across replugs.
  6. Device ID — Windows PnP identifier, which incorporates the serial number. Redacted.
  7. Hardware IDs — Driver-matching IDs built from Vendor ID, Product ID, and revision. No serial embedded — safe to keep.
  8. Driver KeyName — Registry key for this specific driver binding. Redacted — varies by machine/install history.
  9. Driver — usbccgp.sys, the Microsoft USB Common Class Generic Parent driver — this is the node that performs the composite-device split described above.
  10. Driver Inf — The Windows INF describing driver-to-hardware matching for this device.
  11. Class — USB, the generic USB device setup class.
  12. Service — usbccgp, the service backing the driver above.
  13. Location Info — Physical location string (port on which internal hub).
  14. Container ID — GUID grouping every function/interface belonging to this one physical device. Redacted — usable as a stable device fingerprint.
  15. Capabilities — 0x94 = Removable, UniqueID, SurpriseRemovalOK.
  16. Status — PnP node status flags: driver loaded and started successfully.
  17. Lower Filters — Kernel filter drivers below the main stack: vhf (Virtual HID Framework) and logi_lamparray (Logitech's RGB LampArray filter).
  18. First Install Date — Date this hardware ID was first installed on this system.
  19. Last Arrival Date — Most recent plug-in/enumeration date.
  20. Power State — D0 = fully powered/operational.

Connection Information

Device Address:        0x08                                                             # (1)!
Is Hub:                no                                                               # (2)!
Device Bus Speed:      Full-Speed                                                       # (3)!
Number of Open Pipes:  2                                                                # (4)!
Pipe[0]: EndpointID=1  Direction=IN  Type=Interrupt  wMaxPacketSize=0x08  bInterval=1   # (5)!
Pipe[1]: EndpointID=2  Direction=IN  Type=Interrupt  wMaxPacketSize=0x14  bInterval=1   # (6)!
  1. Device Address — USB bus address (1–127) assigned during enumeration.
  2. Is Hub — Whether the device is itself a hub. no — this is an end-device.
  3. Device Bus Speed — Speed class actually negotiated for this session.
  4. Number of Open Pipes — Active data pipes beyond the default control pipe.
  5. Pipe[0] — 8-byte Interrupt IN endpoint, 1 ms interval; carries the boot-protocol mouse report (buttons, X/Y, wheel) — this is the pipe that lets the mouse work in a BIOS or before drivers load.
  6. Pipe[1] — 20-byte Interrupt IN endpoint, 1 ms interval; carries the extended HID report for extra buttons, DPI shift, and other G502-specific controls — highlighted because these two pipes are the concrete example of the Interrupt-transfer guarantee described above.

USB Protocol Support

Usb110:               yes    # (1)!
Usb200:               yes    # (2)!
Usb300:               no     # (3)!
DevIsOpAtSsOrHigher:  no     # (4)!
DevIsSsCapOrHigher:   no     # (5)!
  1. Usb110 — Port supports the USB 1.1 protocol tier.
  2. Usb200 — Port supports the USB 2.0 protocol tier (High-Speed capable).
  3. Usb300 — Port itself doesn't natively support USB 3.0/SuperSpeed — handled by the separate companion port (1-13-1).
  4. DevIsOpAtSsOrHigher — Whether the device is currently operating at SuperSpeed or above. no.
  5. DevIsSsCapOrHigher — Whether the device hardware is even capable of SuperSpeed. no — Full-Speed-only by design.

Device Descriptor (Raw)

bLength:             18      # (1)!
bDescriptorType:     0x01    # (2)!
bcdUSB:              0x0200  # (3)!
bDeviceClass:        0x00    # (4)!
bMaxPacketSize0:     64      # (5)!
idVendor:            0x046D  # (6)!
idProduct:           0xC08B  # (7)!
bcdDevice:           0x6900  # (8)!
bNumConfigurations:  1       # (9)!
  1. bLength — Size of this descriptor in bytes (always 18).
  2. bDescriptorType — 0x01 = Device Descriptor.
  3. bcdUSB — USB spec version claimed, BCD-encoded (0x0200 = "2.00") — a compliance claim, not a guarantee of High-Speed operation.
  4. bDeviceClass — 0x00, highlighted because it's the tell that this is a composite device: class/subclass/protocol are deferred to the interface level rather than declared here.
  5. bMaxPacketSize0 — Maximum packet size, in bytes, for control endpoint 0.
  6. idVendor — Same Vendor ID as the summary, as raw descriptor data.
  7. idProduct — Same Product ID as the summary, as raw descriptor data.
  8. bcdDevice — Device firmware/release version, BCD-encoded (0x6900 ≈ "69.00").
  9. bNumConfigurations — Number of configurations offered; most simple peripherals expose just one.

Configuration Descriptor

wTotalLength:         59               # (1)!
bNumInterfaces:       2                # (2)!
bConfigurationValue:  1                # (3)!
iConfiguration:       "U169.00_B0009"  # (4)!
bmAttributes:         0xA0             # (5)!
MaxPower:             300 mA           # (6)!
  1. wTotalLength — Combined size, in bytes, of this descriptor plus every interface/HID/endpoint sub-descriptor beneath it.
  2. bNumInterfaces — Highlighted because this is the number that makes the device composite: two interfaces (boot-protocol mouse + extended HID) share one physical device.
  3. bConfigurationValue — Identifier the host uses to select this configuration during SET_CONFIGURATION.
  4. iConfiguration — String index resolving to a firmware/build version string.
  5. bmAttributes — Power attribute bitmask: bus-powered, Remote Wakeup supported.
  6. MaxPower — Maximum requestable current, in 2 mA units (0x96 = 150 × 2 mA = 300 mA).

Interfaces & HID Descriptors

bInterfaceNumber:        0                                  # (1)!
bInterfaceClass:         0x03                               # (2)!
bInterfaceSubClass:      0x01                               # (3)!
bInterfaceProtocol:      0x02                               # (4)!
bcdHID:                  0x0111                             # (5)!
ReportDescriptorLength:  67                                 # (6)!
Endpoint:                0x81 IN, Interrupt, 8 bytes, 1 ms  # (7)!
  1. bInterfaceNumber — Index of this interface within the configuration.
  2. bInterfaceClass — 0x03 = HID class — highlighted along with SubClass/Protocol as the exact triad the OS matches to a driver.
  3. bInterfaceSubClass — 0x01 = Boot Interface Subclass — supports the simplified BIOS/pre-driver "boot protocol."
  4. bInterfaceProtocol — 0x02 = Mouse protocol, one of the two standard boot protocols (the other is Keyboard).
  5. bcdHID — HID class spec version implemented (1.11).
  6. ReportDescriptorLength — Size, in bytes, of the HID Report Descriptor defining this interface's data layout.
  7. Endpoint — Single Interrupt IN endpoint delivering boot-protocol mouse reports.
bInterfaceNumber:        1                                   # (1)!
bInterfaceClass:         0x03                                # (2)!
bInterfaceSubClass:      0x00                                # (3)!
bInterfaceProtocol:      0x00                                # (4)!
bcdHID:                  0x0111                              # (5)!
ReportDescriptorLength:  151                                 # (6)!
Endpoint:                0x82 IN, Interrupt, 20 bytes, 1 ms  # (7)!
  1. bInterfaceNumber — Index of this second interface — same physical device, distinct logical function.
  2. bInterfaceClass — 0x03 = HID class, same family as Interface 0.
  3. bInterfaceSubClass — 0x00 = None — this interface skips the boot protocol entirely.
  4. bInterfaceProtocol — 0x00 = None — a vendor-defined report layout is used instead of a standard boot protocol.
  5. bcdHID — Same HID spec version as Interface 0.
  6. ReportDescriptorLength — Larger descriptor (151 bytes) reflecting extra buttons, DPI switching, and other extended G502 features the boot protocol can't express.
  7. Endpoint — Larger Interrupt IN endpoint (20 bytes) carrying the extended, higher-resolution/multi-button reports.

Report descriptor bytes unavailable

Both HID Report Descriptors failed to read (ERROR_INVALID_PARAMETER), a known limitation of the Win32 USB API when querying class-specific HID report descriptors directly, rather than through the HID API (HidD_GetPreparsedData / hid.dll).

Driver Stack: How the Split Plays Out

Composite device, multiple driver layers

This is the concrete version of the "Composite Devices & the Driver Split" section above: the raw USB function (usbccgp.sys, covered above), a generic HID-over-USB transport layer (hidusb.sys), and a class-specific mouse driver (mouhid.sys) that Windows actually reads input from.

Layer: USB Input Device (HID Class Driver)

Device Description:        "USB Input Device"                                                  # (1)!
BusReported Device Desc:   "G502 HERO Gaming Mouse"                                            # (2)!
Kernel Name (PDO):         "\Device\00000084"                                                  # (3)!
Device ID:                 "[redacted]"                                                        # (4)!
Hardware IDs:              "USB\VID_046D&PID_C08B&REV_6900&MI_00 USB\VID_046D&PID_C08B&MI_00"  # (5)!
Driver KeyName:            "[redacted]"                                                        # (6)!
Driver:                    "\SystemRoot\System32\drivers\hidusb.sys"                           # (7)!
Driver Inf:                "C:\WINDOWS\inf\input.inf"                                          # (8)!
Class:                     HIDClass                                                            # (9)!
Service:                   HidUsb                                                              # (10)!
Location Info:             "0000.0014.0000.001.001.000.000.000.000"                            # (11)!
Manufacturer Info:         "(Standard system devices)"                                         # (12)!
Capabilities:              0x80                                                                # (13)!
Status:                    0x0180200A                                                          # (14)!
SelectiveSuspendEnabled:   0                                                                   # (15)!
EnhancedPowerMgmtEnabled:  1                                                                   # (16)!
Power State:               D0                                                                  # (17)!
  1. Device Description — Generic driver-assigned label for this node, not the device's own product string.
  2. BusReported Device Desc — The device's actual product string, preserved even though this layer's own description is generic.
  3. Kernel Name (PDO) — Internal PDO name at the HID transport layer; session-specific, not unique across reboots.
  4. Device ID — PnP ID including a per-enumeration instance suffix. Redacted.
  5. Hardware IDs — Driver-matching IDs for Interface 0 specifically (MI_00) — the composite split in action.
  6. Driver KeyName — Registry key for this specific driver binding instance. Redacted.
  7. Driver — hidusb.sys, exposes a raw USB HID interface as a standard Windows HID collection.
  8. Driver Inf — Generic Windows INF for any standard HID input device.
  9. Class — HIDClass, Windows setup class for Human Interface Devices.
  10. Service — HidUsb, the service backing the driver above.
  11. Location Info — Topological location string; safe to keep, identifies port not physical unit.
  12. Manufacturer Info — Generic Microsoft placeholder at this layer.
  13. Capabilities — 0x80 = SurpriseRemovalOK only, at this layer.
  14. Status — Driver loaded, started, user-disableable.
  15. SelectiveSuspendEnabled — 0 = disabled; common for gaming mice, avoids wake-from-idle input lag.
  16. EnhancedPowerMgmtEnabled — Whether enhanced USB power management is active here.
  17. Power State — D0 = fully on.

Layer: HID-Compliant Mouse (Mouse Class Driver)

Device Description:   "HID-compliant mouse"                      # (1)!
Device Path (HID):    "[redacted]"                               # (2)!
Device Path (Mouse):  "[redacted]"                               # (3)!
Kernel Name:          "\Device\0000008f"                         # (4)!
Device ID:            "[redacted]"                               # (5)!
Hardware IDs:         "HID\VID_046D&PID_C08B&REV_6900&MI_00 HID\VID_046D&PID_C08B&MI_00 HID\VID_046D&UP:0001_U:0002 HID_DEVICE_SYSTEM_MOUSE HID_DEVICE_UP:0001_U:0002 HID_DEVICE"  # (6)!
Driver KeyName:       "[redacted]"                               # (7)!
Driver:               "\SystemRoot\System32\drivers\mouhid.sys"  # (8)!
Driver Inf:           "C:\WINDOWS\inf\msmouse.inf"               # (9)!
Class:                Mouse                                      # (10)!
Service:              mouhid                                     # (11)!
Manufacturer Info:    "Microsoft"                                # (12)!
Capabilities:         0xA0                                       # (13)!
Status:               0x0180200A                                 # (14)!
Power State:          D0                                         # (15)!
  1. Device Description — Standard Windows label for a generic mouse HID usage — appears under "Mice and other pointing devices."
  2. Device Path (HID) — Interface path under GUID_DEVINTERFACE_HID, for raw HID access. Redacted.
  3. Device Path (Mouse) — Interface path under GUID_DEVINTERFACE_MOUSE, used by applications reading mouse input. Redacted.
  4. Kernel Name — Internal PDO name at this driver layer.
  5. Device ID — PnP ID for this HID mouse node, instance-specific. Redacted.
  6. Hardware IDs — Full fallback chain from exact VID/PID/interface down to the generic HID_DEVICE catch-all — UP:0001_U:0002 is HID Usage Page 1 (Generic Desktop), Usage 2 (Mouse).
  7. Driver KeyName — Registry binding key for this instance. Redacted.
  8. Driver — mouhid.sys, translates generic HID mouse reports into the standard Windows mouse input stream.
  9. Driver Inf — Built-in INF for the generic Microsoft mouse class driver.
  10. Class — Mouse, the Windows setup class for pointing devices.
  11. Service — mouhid, the service backing the driver above.
  12. Manufacturer Info — Microsoft, not Logitech — this generic class driver owns the layer, not the device's own firmware string.
  13. Capabilities — 0xA0 = SilentInstall + SurpriseRemovalOK.
  14. Status — Same driver-loaded/started/disableable flags as the layer above.
  15. Power State — D0, fully powered.

Parsed Mouse Capabilities

Input Data Queue Length:  2                         # (1)!
Mouse Identifier:         256                       # (2)!
Number of Buttons:        16                        # (3)!
Sample Rate:              0                         # (4)!
Manufacturer (HID):       "Logitech"                # (5)!
Product (HID):            "G502 HERO Gaming Mouse"  # (6)!
Serial Number (HID):      "[redacted]"              # (7)!
  1. Input Data Queue Length — Number of input reports Windows buffers before older ones are dropped.
  2. Mouse Identifier — Internal numeric ID Windows assigns to this mouse instance among all attached pointing devices.
  3. Number of Buttons — Matches the G502's usage range (Button 1–16), even though far fewer are physically present — extra virtual buttons are exposed for software-mapped actions.
  4. Sample Rate — 0 — the legacy mouse-class driver doesn't populate this for HID mice; actual USB polling interval is 1 ms, per the Interrupt endpoints above.
  5. Manufacturer (HID) — Matches the USB descriptor value, read through the HID API layer instead.
  6. Product (HID) — Matches the USB descriptor value, read through the HID API layer instead.
  7. Serial Number (HID) — Same per-unit serial as elsewhere in this report. Redacted.

HID Report Descriptor Capabilities

UsagePage:                  0x0001 (Generic Desktop Controls)  # (1)!
Usage:                      0x0002 (Mouse)                     # (2)!
InputReportByteLength:      9                                  # (3)!
OutputReportByteLength:     0                                  # (4)!
FeatureReportByteLength:    0                                  # (5)!
NumberLinkCollectionNodes:  2                                  # (6)!
NumberInputButtonCaps:      1                                  # (7)!
NumberInputValueCaps:       4                                  # (8)!
NumberInputDataIndices:     20                                 # (9)!
  1. UsagePage — Generic Desktop Controls, the standard page for pointing/positional devices.
  2. Usage — Mouse, identifying the overall collection's purpose.
  3. InputReportByteLength — 9 bytes: 1 report/button byte + 2×16-bit X/Y + Wheel + AC Pan.
  4. OutputReportByteLength — 0 — no output reports (no LEDs/rumble on this collection).
  5. FeatureReportByteLength — 0 — no feature/configuration reports on this parsed collection.
  6. NumberLinkCollectionNodes — Two: an outer Application collection (Mouse) containing an inner Physical collection (Pointer).
  7. NumberInputButtonCaps — One capability range, covering all 16 buttons.
  8. NumberInputValueCaps — Four value fields: X, Y, Wheel, AC Pan (below).
  9. NumberInputDataIndices — 16 button + 4 value indices, individually queryable via the HID API.

Collections

Collection[0]:  "Mouse (Application)"      # (1)!
Collection[1]:  "Pointer (Physical)"       # (2)!
  1. Collection[0] — Outer, top-level "Application" collection — the self-contained mouse device.
  2. Collection[1] — Nested "Physical" collection for the sensing element, grouping X/Y/wheel/button fields.

Input Button Capability

UsagePage:       0x09 (Buttons)  # (1)!
IsVariable:      yes             # (2)!
IsAbsolute:      yes             # (3)!
UsageMin:        "Button 1"      # (4)!
UsageMax:        "Button 16"     # (5)!
DataIndexRange:  "0 – 15"        # (6)!
  1. UsagePage — 0x09, the standard page for pushbutton controls.
  2. IsVariable — Each button its own independent bit, rather than an enumerated single-value array.
  3. IsAbsolute — Pressed/not-pressed at a point in time, not a relative delta.
  4. UsageMin — Lowest button usage in this range.
  5. UsageMax — Highest button usage — 16 total, matching "Number of Buttons" above.
  6. DataIndexRange — Contiguous block of HID data indices for these 16 buttons.

Input Value Capabilities

X-Axis:  Usage=Direction-X  BitSize=16  Range="-32767 to 32767"  Relative=yes                 # (1)!
Y-Axis:  Usage=Direction-Y  BitSize=16  Range="-32767 to 32767"  Relative=yes                 # (2)!
Wheel:   Usage=Wheel        BitSize=8   Range="-127 to 127"      Relative=yes                 # (3)!
AC Pan:  Usage=AC Pan       UsagePage=Consumer  BitSize=8  Range="-127 to 127"  Relative=yes  # (4)!
  1. X-Axis — Signed 16-bit relative delta per report — movement since the last report, not an absolute coordinate.
  2. Y-Axis — Same relative signed 16-bit encoding as X.
  3. Wheel — 8-bit signed relative delta per report — up to ±127 "clicks" of scroll.
  4. AC Pan — Horizontal scroll (tilt wheel/side-scroll), defined under the Consumer usage page rather than Generic Desktop — also an 8-bit signed relative delta.

String Descriptors

String[0]:  "Language 0x0409 (English - United States)"  # (1)!
String[1]:  "Logitech"                                   # (2)!
String[2]:  "G502 HERO Gaming Mouse"                     # (3)!
String[3]:  "[redacted]"                                 # (4)!
String[4]:  "U169.00_B0009"                              # (5)!
  1. String[0] — Language ID Descriptor, listing available languages for the device's strings.
  2. String[1] — Manufacturer string, referenced by iManufacturer.
  3. String[2] — Product string, referenced by iProduct.
  4. String[3] — Serial number string, referenced by iSerialNumber. Redacted — same reason as the Serial field above.
  5. String[4] — Configuration string containing a firmware build identifier (the original descriptor carries trailing whitespace padding, a known quirk of this device's firmware).

Redaction summary

The following fields were replaced with [redacted] across every driver layer (USB parent, HidUsb, and mouhid) because they can identify or fingerprint this specific physical unit or installation instance: Serial Number (summary, HID info block, and String Descriptor 3), all Device Path values (GUID_DEVINTERFACE_HID, GUID_DEVINTERFACE_MOUSE, GUID_DEVINTERFACE_USB_DEVICE), all Device ID values, Container ID, all Driver KeyName values, and CompanionHubSymLnk. Vendor/Product IDs, class codes, descriptor lengths, HID usage/collection data, and protocol values were retained throughout — generic, publicly documented specification data rather than per-unit identifiers.

Other Composite Devices, for Comparison

How other everyday devices split their interfaces
  • Webcam — one Video (UVC) interface for the image stream, plus one Audio interface for the built-in microphone; two completely different class drivers on one device.
  • Smartphone (USB debugging + storage mode) — a Vendor-Specific interface for ADB, alongside Mass Storage or MTP interfaces for file access.
  • USB-C Dock — a Hub interface, plus separate Video, Audio, Mass Storage (SD card reader), and CDC (Ethernet) interfaces, all behind one cable.
  • This G502 mouse — two HID interfaces sharing one class, split only by SubClass/Protocol and report layout, exactly as detailed above.

Useful Resources

  1. USB Implementers Forum. (n.d.). Universal Serial Bus Specification. https://www.usb.org/documents ↩↩↩

  2. USB Implementers Forum. (n.d.). Device Class Definition for Human Interface Devices (HID). https://www.usb.org/hid ↩

  3. Wikipedia contributors. (n.d.). USB. Wikipedia. https://en.wikipedia.org/wiki/USB ↩

  4. Microsoft. (n.d.). USB Common Class Generic Parent Driver (Usbccgp.sys). Microsoft Learn. https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-common-class-generic-parent-driver ↩