Chris G wrote:
In my experience it's just par for the course when using USB. Many of my current issues and problems with computers seem to be with USB devices. Often it's trying to get VirtualBox to handle a USB device and other such things. I've also found that a USB to ethernet adapter just fails to work completely in Linux.
USB is inevitably complex because there are so many possible 'things' that can be plugged in. Mass storage devices are handled pretty well because they're so common but the moment you move away into other sorts of devices things become less certain.
I'm not sure that is the specific cause of the problem. There are plenty of other interfaces that have a similar selection of device types or devices on other interfaces that present the same issues.
Most of the issue I think is due to more intelligence being put into the driver rather than the device itself. The unit cost of adding some code to the driver once vs adding a chip to each device means that no longer are we looking at simple data in - data out.
Now the driver can be performing device initialisation routines, loading up the device firmware (rather than it being in ROM on the device), performing error correction and status monitoring. Winmodems were an early example.
Of course this doesn't do OSS any favours because now it is more likely that technical advantages between one product and a competitor can be in the drivercode rather than hidden in the device itself. Consider a printer from company X that prints photos better than company Y's device because of some cleverness in the dithering algorithm. Now with printers where the dithering is done by the print driver there would be an issue in releasing an open driver with the same functionality as the closed one.
This is probably more prevailant on USB simply because generally we are looking at a cheaper selection of devices that have limitations (if bus powered) on how much they can actually do on circuit. Host CPU cycles are cheap (to the device manufacturer) and plentiful on modern computers so it is inevitable that the driver ends up doing more than just being a device interface.
Lots of the issues on the linux-usb list were down to devices which didn't follow the rules but had bodged windows drivers so that they work successfully with MS-Windows. The changes and patches to the Linux USB drivers were adding code to work around these bodges for each specific device.
Well the thing is there are no "rules" beyond electrical and physical characteristics. Sure there are generic models for say mass storage or USB printing or input devices but nothing says that anyone has to implement them 100%, or even at all.
So it is natural that the implementation is only taken up to the point it needs to be for the device to work on the supported platforms or if a device bug is found it is coded around in the driver. The reason that mass storage tends to "just work" is that it is preferable that the devices work on any machine without driver installation due to their nature of being used to transfer data between machines.