Slashdot Mirror
Freedreno Graphics Driver Gets PRIME, Render Node Support
Via Phoronix comes news that the new DRM driver for the Freedreno driver for Qualcomm Snapdragon Adreno graphics is gaining a few new features in Linux 3.13: "After a year of working on the 'Freedreno' Gallium3D user-space driver and getting that up to speed for Qualcomm Adreno/Snapdragon support, for the past few months he's been working on a complementary kernel driver rather than relying upon Qualcomm's Android-focused kernel layer. ... The work that Rob has ready for Linux 3.13 with this Qualcomm DRM graphics driver is DRI PRIME support, support for render nodes, updated header files, plane support, and a couple of other changes."
I'm guessing that doesn't mean Digital Rights Management in this context?
Unless the contrary is specifically mentioned, it's probably a safe assumption. I suspect that the question will be 'is the proprietary firmware stored on the device, or loaded by the driver, and if it is loaded by the driver, are Qualcomm going to be total dicks about redistribution of the firmware blob?'
While, in an ideal world, having the firmware also be OSS would be nice (and, in the case of something like motherboard firmware, which is something approaching the complexity and power of a full OS, running silently underneath the OS that you can see, all the time, increasingly likely to be necessary for the product to be 'free' in any operationally useful sense, rather than being a proprietary blackbox that is kind enough to permit you to exist inside a hypervised sandbox, like the PS3 used to), the thing that is really annoying is companies who hassle you about mere redistribution of unaltered firmware images purely for the purposes of using their products. There isn't really a 'freedom' difference between the parts that store all their firmware in flash, and the parts that have just enough brain to wake up and receive their firmware blob from their driver on startup(if anything, parts that store the blob offsite are probably easier targets for reverse engineering, and harder to brick); but unless you can redistribute the blob, there sure is a convenience difference...
Back in the NSLU2 days (233MHz StrongARM for only $99... how far we've come), that was the case with the NIC firmware for some inscrutable reason. If you wanted to use the built-in NIC, you needed to go through a clickwrap license agreement with Intel, despite the fact that the firmware you were 'licensing' was totally useless for any purpose except to use part of the silicon purchased from Intel. Just pure, pointless, hassle.
The three of us who want to run Linux on our Xperia Play are excited.
Seriously though, more open driver support for ARM-related GPUs is exciting Linux news. The driver support for Mali is the reason I went RK3188. If I'd known this was coming I might have chosen a different platform.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I don't claim to know the details, in either case (though, given that Intel makes NICs, and made StrongARMs at that time, I'm inclined to accuse them for not doing it themselves or using their Chipzilla powers to muscle a suitable agreement out of their supplier). My intended point was just that I don't understand the people who treat devices that treat devices with proprietary firmware burned into onboard flash as 'more free' than devices that request proprietary firmware on startup (since they both use proprietary firmware, one just skimps on the BoM and the other doesn't); but I do see a very significant difference in usability between vendors who are laid back about their firmware blobs, whether they are burned in or requested at power-on, vs. the vendors who treat their blobs as precious secrets and force you to go through some silly little dance to get the things. (Of course, the special place in hell is reserved for the vendors who treat the blobs, when distributed alone, as some terrifying threat; but treat the Windows driver, with the blob included so that that driver can load it, as an item on their support page. How, exactly, does my having to download win32driver.exe, then run driverdissector.sh, to get firmware.bin do anything other than annoy me, at no benefit to you, whose silicon I've already purchased?)