midnight-wonderer
commented
7 months ago 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?
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:
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:
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.)