Suggestion: Class-generic PIDs for testing and prototype purposes

[xcvista]

This suggestion seeks reserving 16 PIDs as class-generic PIDs that is suitable for devices implementing one of the five most frequently used device classes that most modern operating systems carry device class drivers, or a combination of them in a composite device:

• USB HID,
• USB MSC (Flash drives)
• USB CDC ACM (USB Serial)
• USB CDC NCM (USB Ethernet)
• USB DFU (bootloaders, special case in PID allocation)

The 16 reserved PIDs share the same high nibbles, and form a 4-bit bitfield in the lowest nibble of the PID. Setting the bit means the function in question exists in the device exactly once, and clearing it means the function does not exist in the device. The bit allocations are:

• HID = 0b0001,
• MSC = 0b0010
• CDC_ACM = 0b0100,
• CDC_NCM = 0b1000

A special case is made when all four bits are zero. This PID indicates a class-generic USB DFU device, intended to be used by bootloaders.

In this way each class-generic PID corresponds to exactly one USB device driver or one combination of them. Devices using those class-generic PIDs have to distinguish from each other using other methods, for example USB strings, serial numbers, or HID report descriptors. They also must work with the default driver shipped in most modern operating systems (user-mode applications does not count as drivers.)

[midnight-wonderer]

I want also to mention VOTI (VID: 0x16c0).

They reserved these PIDs for sharing.

PID	Description
05dc	shared ID for use with libusb
05df	HID device except mice, keyboards, and joysticks
05e1	shared USB VID/PID pair for CDC devices
05e4	Free shared USB VID/PID pair for MIDI devices
27d8	libusb-bound devices
27d9	HID device except mice, keyboards, and joysticks
27da	Mouse
27db	Keyboard
27dc	Joystick
27dd	CDC-ACM class devices (modems)
27de	MIDI class devices

I wonder if pid.codes can reserve something similar, too?