Qualcomm's Open Kernel Driver Leads To A Dirty Mess
Written by Michael Larabel in Hardware on 1 July 2010 at 08:37 PM EDT. 17 Comments
Well, it sounded nice when Qualcomm announced an open-source 2D/3D kernel driver for their Snapdragon platform that's used by phones like the Nexus One and Dell Streak, but it turns out that their user-space Linux driver that hooks into this kernel driver is currently a closed-source blob. This has led to the eternal debate about open-source kernel components but with only closed-source components.

Right now it turns out that Qualcomm's user-land code that talks to this driver is not open-source but their kernel driver is, which touches the hardware and provides the support for interrupts, command streams, context switching, memory management, etc. The driver supports the essentials of DRI2, but both sides of this driver largely communicate via this KGSL (Kernel GSL) HAL that was devised by Qualcomm along with their own ioctl. Having an open-source kernel side but closed-source user-space is nothing new (a.k.a. partially open-source drivers), but VIA has had the problem with their Chrome 9 DRM, but still the code hasn't been mainlined.

As this situation has cropped up again (and this situation is likely to occur more often in the future), Red Hat's David Airlie who maintains the DRM for the Linux kernel and does a great deal of Linux graphics work, he has clarified his policies. Simply put, "If you aren't going to create an open user-space driver (either MIT or LGPL) then don't waste time submitting a kernel driver to me."

The basis for not accepting an open-source kernel driver that's only user is a closed-source user-space component is due to licensing with derived work concerns, verifying the sanity of the user-space API without any open-source user-space component to test, general API suitability and version differences, the possibility for multiple drivers to develop if only documentation is provided, and the trend of reinventing the whole driver stack rather than taking advantage of existing DRM/KMS APIs. David's response in whole can be read on dri-devel.

If Qualcomm wishes to retain a closed-source user-space driver while getting their kernel driver mainlined, the path they will likely need to take is creating an open-source user-land driver that takes full advantage of their kernel interfaces even if this open-source driver doesn't provide the same in-depth feature-set as their proprietary driver. In a perfect world, they could just open up their user-space driver and be all set.

The discussion over this topic and Qualcomm's options are ongoing within the DRI and Linux Kernel mailing lists.
About The Author
Author picture

Michael Larabel is the principal author of Phoronix.com and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated benchmarking software. He can be followed via Twitter or contacted via MichaelLarabel.com.

Related Hardware News
Popular News
Trending Reviews & Featured Articles