Qualcomm Makes Open-Source 3D Snapdragon Driver

An anonymous reader writes "Qualcomm today posted the source code to a Linux kernel driver for 2D/3D support on its OpenGL ES Core found on Snapdragon-based phones like the Nexus One. The company is trying to get this driver into the mainline Linux kernel, but it turns out that the user-space driver is still not open source, which has resulted in some problems already. The ongoing discussion can be found on FreeDesktop.org."

Re:This is the great thing about Android.

[linuxgeek64]

Er, nevermind. Free Software. I fail as usual.

Re:This is the great thing about Android.

[ThePengwin]

The Term FOSS would have been better :)

Re:This is the great thing about Android.

[marcansoft]

Too bad this driver isn't open source. Sure, the kernel component might be, but as the announcement itself clearly states, kernel 3D drivers are really just resource managers. The real driver lives in userland, and that part isn't open source. Phoronix is hoping it will be, but I've seen no clear indication of that.

Don't hold your breath. Nothing says the userspace component will be open sourced. Without that, this isn't even remotely an open-source 3D graphics driver. This is just an attempt to take advantage of a mainline driver being constantly updated and maintained with the kernel, without actually releasing the source to the part that matters (the userspace part).

Re:It's nice to see kernel hackers understand ...

[MostAwesomeDude]

It's not new-found. This has been policy for a long time, and has been applied to e.g. OMAP SGX and Poulsbo/Moorestown patchsets. This is more of a link to which we can direct people asking stupid questions on IRC.

Command stream protocol?

[White Flame]

So nosing through the posted code, it seems like it deals with shuffling commands through to the chip, but I don't see any header files helping to define what data gets sent through the actual "issueibcmds" call. There's some gfx-level stuff in yamato_reg.h so I could be wrong.

I guess companies like this want to keep their trade secret optimization techniques in how they convert OpenGL state to chip buffer commands, but if they would open up the actual chip-level communications then the community could create their own open source OpenGL layers. I suspect there's a lot of command styles and user-space optimization techniques that could be reused across multiple chipsets, yielding a lot of benefit to true open source 3d hardware acceleration drivers. I just really don't understand their business case for not letting people develop new software to their chip, even if their proprietary driver stays proprietary.

Plus, WHERE ARE THE COMMENTS? Does nobody actually document their code anymore? This is your companies' public relation and an olive leaf to the Linux community for crying out loud! Show at least some semblance of competence in writing maintainable software!

Re:This is for you RIM, Nokia, Microsoft and Apple

[dwater]

Also, I think the underlying issue in this story is about Open Source (rather than Linux), and I think even Symbian is more Open Source than Android is.

I say that mainly because of Symbian's open governance model - ie no one company has control. The same can be said of MeeGo, and Qt is heading that way too.

Symbian also gives you many more choices for development than Android - there's a whole wealth of programming languages to choose from.

In many ways, Nokia is really doing Open Source like very few other companies. I don't know if the upper echelons really get it (maybe), but the I'm certain many (majority even) of the engineers do - FOSS really is at the heart of the company.

Re:Command stream protocol?

[White Flame]

Ok, I shouldn't post that fast. ;-) It seems that kgsl_pm4types.h does at least describe the commands shipped off to the chip, so somebody willing to put the effort into banging away at it could generate actual high-level documentation on how to use the chip via trial-and-error and/or intercepting command buffers from simple OpenGL test programs through the userland blob through this driver.

Seeing such documentation exist with the code already would of course be the better situation, and I still don't see any barrier for Qualcomm to release that given as much as they've released now.

If we could only get kernel source to use this...

[doowod]

Drivers are nice and all, but you need a kernel to compile them into.

In the case of the Snapdragon-powered Sprint Evo, HTC [htc.com] still hasn't released kernel source after a month of distributing the binary kernel. Despite the fact that GPLv2 [gnu.org] requires them to release the source along with the binary...

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

For the Nexus One, HTC waited around 6 months after releasing the phone to release the kernel source. The HTC Hero still doesn't have the most current source released.

It's sad to see that the manufacturer of flagship phones for every major US mobile phone carrier [gizmodo.com] (other than AT&T) has no respect for the GPL and has reduced developers to reverse engineering Linux kernel sources [xda-developers.com], asking clueless customer service reps for a source release [xda-developers.com], and generally trying everything they can think of without getting any positive results at all [xda-developers.com].