19.5 Nonconforming USB Devices

There are debates on how best to handle devices that do not conform to the USB Specification. It is recommended that the driver stack comply with the USB Specification and reject any nonconforming devices. A nonconforming device that is not linked into the USB software stack should not interact further with the system.

However, even if the device is nonconforming and the USB driver stack should reject it, developers need to make sure that the nonconforming device does not cause system failures. The developer must not make any assumptions about the device's behavior, especially since, once a system is known not to conform, its behavior cannot be trusted. It can respond to addressing that was not meant for that device; it can corrupt data going into it and coming back from it; and it cannot be trusted to perform its intended function(s). It is essential for the end-user's experience that the nonconforming device does not negatively affect the system.

A driver can only reliably reject nonconforming devices that it already knows about. For USB devices, the identity of devices may be determined by use of the data in the USB device description packets.

USB devices have several sets of known issues that may be detected and hidden from the user. For example, some keyboards auto-repeat when keys are pressed for an extended period of time. In this case the consuming driver should simply ignore packets which repeatedly provide identical information. Media devices also have several issues. USB requires implementation of the SCSI or ATAPI specifications, which, for many e.g. thumb drives, is beyond their capacity. As such, relying only on basic commands can greatly increase the probability of functionality.