When Device Support Goes Beyond Drivers
by Kristin Shoemaker - Nov. 09, 2008Comments (1)- Related Blog Posts
- 10 Of OStatic's Most Popular Open Source Educational Resources
- Ubuntu Enterprise Cloud Services Helps Users Build (and Support) Private Clouds
- Moblin Arrives in Beta 2.0 Version, Works With Netbooks
- OStatic Buffer Overflow...
- HTC's Hero Phone: The First Android Device to Run Flash
I've been doing some thinking since writing about kernel developer Greg Kroah-Hartman's statement that Linux supports more devices than any other operating system. Readers made some good comments, and after some time spent wrestling with my (yes, supported) webcam, I can venture an additional suggestion as to why it doesn't always seem that way, beyond Kroah-Hartman's theory of a non-supported device becoming "personal."
In the case of my webcam, and in the case of one commenter, it seems the problem isn't necessarily the device driver. At lower levels, the drivers work. It's the layers of programming, interaction, and demand piled on the driver that makes the device feel broken. It is difficult to tell for sure, though, exactly what is causing that break.
A reader left a comment on the original story that his ATI video drivers do not work at all with Compiz and video playback, or particularly well with WINE. I have not personally seen this problem, but I've heard others talk about similar issues (with different card manufacturers). This is, however, a complicated issue to deconstruct. I don't think it can honestly be said that the device in question isn't supported. I am making the assumption that whatever driver module is being used -- fglrx, radeon, ati -- works with the compositor disabled, or perhaps even with it enabled, but without video files playing. I am going to avoid the definition of "supported" in this case, as it can mean different things depending on device and user. The driver works, but not in the way that is necessarily desired, or expected. It may be a bug, it may be that the device is better described as "partially supported" or -- and this is the hard part to determine in the case of the graphics driver -- it could be something else entirely.
On the most basic level, there is the hardware itself. Depending on the card and system specs, Compiz and video playback might be a cakewalk, or it might send the whole system to a screeching halt. Then there is the driver, which could have known issues with certain applications and services, specific aspects of applications, or have problems that only surface when two (or more) applications run simultaneously. The issue could be with the graphical server configuration (on some video cards enabling the "Composite" option in Xorg.conf helps, on others it does nothing, and the rest behave so badly it leaves you wondering how the evil spirit got into your computer again), or the issue could be Compiz itself (it is a popular feature, and included in many distributions, but it is fairly new). It could be the video playback that sends it into a tailspin.
It could very well be a driver bug, but as complex and resource intensive software calls on the driver in conjunction with other complex pieces of software, it is just as easily a conflict on a higher level causing problems.
I witnessed this happening this week with my webcam. The camera is officially supported, and uses the uvcvideo driver that was introduced prior to the last kernel release. It is supported, beyond a doubt -- lsmod will show that the driver module is loaded, a well worded dmesg command will show me the device and further driver information. Sending the webcam some simple commands through an xterminal brings it to life, and captures video. With absolutely no-frills, it works.
But feeding a webcam instructions via the command line isn't ideal for most. I have proof positive that my webcam drivers work as intended. It would be impossible to say that and know for sure it's true if I based my experience on the webcam applications I've tried.
The webcam applications I've used (luvcview, Cheese and UCView) all captured video with variable -- and inconsistent -- success rates. The luvcview software was easily the most consistent and stable software, but being that it is designed primarily for testing and troubleshooting, the best help and information it could offer that the webcam was still being recognized by the system after the other two applications crashed and didn't seem to detect the camera upon relaunch.
Again, there could be many factors at play here -- and though driver problems are theoretically possible, I'm more inclined to believe the problems come from the webcam software settings asking for more than the application (and possibly my processor) can comfortably handle. For instance, this was the first time Cheese was able to detect my camera -- Cheese is getting progressively better at dealing with UVC devices, though the driver has been supported. UCView was more reliable in displaying the action the webcam was focused on, but changing settings (such as the output file format, or size and resolution of the capture) would often cause crashes, freezes, or make the application "forget" where the camera was.
These sorts of problems are frustrating all round. It's difficult for end users to imagine where things are going off course when dealing with hardware that has so many layers of software -- especially with facets seemingly unrelated to the function of the hardware or the application accessing the hardware. From the development side -- both kernel development, and desktop application development -- there are challenges in determining (and reproducing) bugs in even very detailed bug reports.
It is a process, at the very least, where communication is key. I have no reason to doubt Kroah-Hartman's statements on device support, especially at the machine/kernel level. It seems that in many cases, the challenge is finding the most efficient, stable way to effectively use the supported devices -- and this challenge should not fall solely on the shoulders of the application development teams.
