Embedded GPUs On Linux Remain A Great Big Mess
For anyone that happens to be on holiday this week (or just have excess time otherwise), there is another lively and polarized discussion that's been taking place for the past several days on the DRI mailing list. What does it involve if it's not about developer disagreements amongst themselves? Embedded GPU driver support on Linux, of course. This mailing list thread just reaffirms how the situation is a great big mess.
For those that haven't already been following this thread or don't have the time to catch up, it just started out as a thread within the Linaro mailing list about reviewing the Freescale Linux BSP code and how to handle it within the Linaro project, which again is the Linux project attempting to unify the ARM platform.
One of the big parts of this Freescale Linux BSP code is a kernel graphics driver. It's open-source, great. But, like the Qualcomm Snapdragon graphics driver and most other embedded GPU Linux drivers (and some of VIA's previous Chrome DRM code), the open-source kernel driver is only good if pairing it with a closed-source user-space component.
Once it was confirmed this newest code was still bound by a closed-source library, the discussion spewed onto the DRI development mailing list. Some though, such as Linaro's Jammy Zhou, proposed the kernel code be integrated into the Linaro kernel tree regardless and then adding the closed-source user-space binaries to the Linaro hardware pack. This though would go against the Linaro policy of pulling in kernel code that's not on its way to hitting the mainline tree. An alternative would be to create a separate, not-officially-maintained Git tree of the Linaro kernel but with all of the kernel graphics bits integrated that are dependent upon being banged from closed-source software.
Besides the legal and philosophical reasons for not accepting open-source Linux kernel code that's only used by closed-source clients, there are technical reasons too. Like not being able to easily audit the code for security holes, being bound to an API/ABI that's just designed for use by the closed-source client, etc.
With GPU drivers, one of the security holes can come from having a GPU driver that could read the system memory. That's why the Radeon DRM driver (and other open-source DRM/KMS drivers) have a command checker to provide some safeguards. Around this time in the thread, Matt Sealey began commenting. Matt Sealey is a Product Development Analyst for Genesi. Genesi is a vendor of ARM-based devices.
Genesi's Sealey began by commenting that worrying about host memory access by the GPU driver is an unneeded worry and then to express his views on kernel driver licensing. "Ownership of the code is dependent on who licensed it. I do not think Linaro need be so concerned over opensourcing or reimplementing drivers. The fact that the kernel driver is open source as it is, and this is by far the most important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done)."
After Jerome Glisse responded asking whether Matt was indeed saying that all open-source code should be accepted into the Linux kernel simply because the code is open-source, this Genesi employee had another entertaining message. Here was his next message.
The code may need improvement but that's no reason to run around saying everything needs to be open sourced, and that the solution is in fact to reverse engineer the thing rather than accept it as the current solution. Given how long nouveau and later Radeon card support has taken in real life, even with full documentation from AMD, I seriously doubt Linaro are going to be the ones to somehow make the world change for OpenSource embedded GPU graphics. Linaro doesn't exist just to spend all their time undermining the status quo for the sake of it.
Matt had also ended his earlier message with, "Can't we all just be happy that we actually have 3D drivers?" David Airlie then jumped into the thread.
Can't you just use Windows? why bother with open source at all if you are willing to give up.
After messages from Alan Cox and others, the Genesi Product Development Analyst got back on the list providing his views on code legal advice and more insightful views from a hardware vendor that doesn't seem to understand Linux.
There is no legal issue here. It is not going into mainline, fair enough. What I am curious about is why did Linaro push it to dri-devel in the first place? I think the concept of taking a driver from a BSP and then just FLINGING it at mainline is not responsible in the first place. Isn't it enough to go into the Linaro tree, discretely and quietly? Then we can have a discussion about what to do about it within Linaro.
It looks like the embedded GPU Linux driver situation will continue to be a mess going into 2011, though there have been some hints otherwise. But at least this messy situation provides for some entertainment on the DRI mailing list.
Latest Linux Hardware Reviews
Latest Linux Articles
Latest Linux News
Latest Forum Discussions