你是否在设备描述符中定义了子类 1 —— 可引导设备？试试将子类改为 0。
During the early development of the HID specification, subclasses were intended
to be used to identify the specific protocols of different types of HID class
devices. While this mirrors the model currently in use by the industry (all devices
use protocols defined by similar popular devices), it quickly became apparent that
this approach was too restrictive. That is, devices would need to fit into narrowly
defined subclasses and would not be able to provide any functionality beyond that
supported by the subclass.
The HID committee agreed on the improbability that subclass protocols for all
possible (and yet to be conceived) devices could be defined. In addition, many
known devices seemed to straddle multiple classifications—for example,
keyboards with locators, or locators that provided keystrokes. Consequently, the
HID class does not use subclasses to define most protocols. Instead, a HID class
device identifies its data protocol and the type of data provided within its Report
The Report descriptor is loaded and parsed by the HID class driver as soon as the
device is detected. Protocols for existing and new devices are created by mixing
data types within the Report descriptor.
Note: Because the parser for the Report descriptor represents a significant
amount of code, a simpler method is needed to identify the device protocol for
devices requiring BIOS support (Boot Devices). HID class devices use the
Subclass part to indicate devices that support a predefined protocol for either
mouse devices or keyboards (that is, the device can be used as a Boot Device).
The boot protocol can be extended to include additional data not recognized by
the BIOS, or the device may support a second preferred protocol for use by the
HID class driver.
The bInterfaceSubClass member declares whether a device supports a boot
interface, otherwise it is 0.
Subclass Code Description
0 No Subclass
1 Boot Interface Subclass
2 - 255 Reserved