Linux Device Support

The Linux Desktop survey from the Linux Foundation is now in full swing. I also Chair the Vendor Advisory Council for the Linux Foundation and recently did a poll of the vendors to identify the top 10 issues inhibiting Linux adoption from the vendors point of view. A recent meeting of the Linux Foundation's Desktop group with the three primary vendors that now pre-install Linux also identified a number of key issues to address. I also have met with the User Advisory Council of the Linux Foundation a number of times to hear their issues. And, there are always surveys online and summaries of installation tests, primarily on desktops.

In all of these sources of end user pain points, I always hear about how device drivers and device support ranks in the top 5 (sometimes top 1 or top 2) issues from each of these groups. I also have some first hand evidence of drivers as a problem, especially when dealing with the ultra-latest in hardware support. At IBM, we set up a "tiger team" to help identify new hardware, work with independent hardware vendors to provide them encouragement and training on how to develop open source drivers. When I was part of OSDL's Data Center Linux effort, I helped develop training information for developers, managers, project managers on how to work drivers into Linux. And, with help from the Linux community, OSDL's legal team, and the Linux Foundation after that, we set up programs to allow vendors to enter into NDA's with Linux driver writers. The goal all along has been to enable vendors to get drivers written, either on their own, or with help from the greater community of Linux driver writers and to have those drivers exist as part of the Linux kernel, available to all users when they install their Linux distribution. And, the Linux community itself has made available over 200 driver writers and 10 project managers to help create device drivers.

Yes, there are holdouts like nVidia who have not embraced the open source driver path. There are challenges in the wireless space related to the FCC operational ranges for transcievers. But by and large, the inhibitors to developing and making device drivers available for hardware have been removed. So, I am somewhat puzzled by the fact that what was clearly the #1 inhibitor to Linux adoption 5 years ago is still on the list as an inhibitor. And, I'm struggling now to find out why. As part of the Linux Foundation, I've pledged to dig into details and attempt to provide concrete lists of devices which need drivers, and honestly, I need help with this. I no longer have a list of devices that are not supported by Linux, and, if I had such a list, I would work all possible channels to get drivers for those devices written and into mainline. And, the list has to be more concrete than some of these comments from the desktop survey:

• hardware problems (USB, bluetooth devices - webcams, headsets, ...)
• Difficulty connecting with some devices.
• Drivers Support for some devices (Printers, WLAN, ..).

There are some better comments in there, such as:

• The need to manually compile drivers for external devices like a usb tv tuner (for example AverMedia provides the driver but there is no user friendly tool to install it and u need console commands knowledge and internet access in order to complete the install)
• Quality drivers. Non-official drivers usually support only a subset of the full capabilities of hardware devices, and even official ones (like the Intel graphics driver, for instance) have a lot of annoying bugs.

But even those are a bit vague. There is also some confusion between "devices" such as printers and scanners (many of which have pass through kernel drivers with user mode application drivers) and those that have a full kernel driver to enable their capability. Of course, that is something that the desktop group can work through over time.

But my primary point here is that getting detail about *what* devices do not have support has been getting much, much harder. People need to provide information about Vendor, Product, Model number, PCI ID, USB ID, etc. to help the community identify what drivers are broken. And, when a driver is missing capability, as is alluded to in the "quality drivers" comment, the missing features need to be identified. Until we have that list of non-functioning or limited-function device, there isn't much that people can do. And, sometimes it is key to continuously let people know that features or devices are not working from release to release. The community often moves so quickly that something broken one day could be fixed the very next, and without a periodic reassessment on the functionality of the device is sometimes necessary.

Oh, and before someone points out the obvious ones, yes, nVidia now has the nouveau driver, ATI has started working with the community to support their graphics devices, Intel is working towards full support of their hardware, most SCSI and SAS devices are currently supported, and there are some rough edges still with MultiPath support that are still in progress. But what else is broken? Surely these few devices can not be the substantial reason that device support is constantly on the top of the list? What other devices do not have driver support? Expose them! That is the best way to get those devices supported!!!