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."

Comments

This is the great thing about Android.

[GNUALMAFUERTE]

It's not only a great system, and it's FS, it's also going to drive other companies to do the same, and open their code.

Re:This is the great thing about Android.

[GNUALMAFUERTE]

FS=Free Software.

I wrote it's. That means "it is". I thought it was pretty clear.

Re:This is the great thing about Android.

[GNUALMAFUERTE]

BTW, where is everyone? I was starting to wonder if the zombie apocalypse had started without me. Noone at /., and no new XKCD yet (It's already 00:08 EST).

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.

[linuxgeek64]

I thought FS meant filesystem because my brain is sorta dead right now. Normally I'd see that it means free software.

Re:This is the great thing about Android.

[Microlith]

Only if it lets me use it with X.

I'd like to see the drivers opened such that I could have one less closed bit, but only having a kernel-side chunk open (or whatever bastardized process they have now) and the userspace stuff still locked to Android or whatever OS came on your device. Oh and to redistribute without being in violation of a license.

I'd love it if the PowerVR SGX drivers for my N900 had source. We could probably make them not suck and turn on VSync.

Re:This is the great thing about Android.

[ThePengwin]

The Term FOSS would have been better :)

Re:This is the great thing about Android.

[MichaelSmith]

Nobody can work because your RSS update interval is set to 100 milliseconds ;)

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:This is the great thing about Android.

[hairyfeet]

That brings up a good question I've always wondered, which is "how far do you push the "Open" part of FOSS"? I mean to hear RMS tell it anything short of GNUSense isn't really "free" because they allow binary blobs and firmware, but at the same time if a company says "take it or leave it" how many times can you say "leave it" before you don't have enough devices to worry about? I mean Nvidia will give you nothing but a binary blob, yet here on /. we hear guys say time and time again to stick to Nvidia even though ATI has opened their specs, so at what point does the Linux community decide features or performance is worth more than freedom?

As for TFA, unless the telecos change their business models I doubt you'll be getting much "free" in a handheld, as crippling phones and locking the hell out of their networks is pretty much SOP, and I just don't see that changing. After all if your phone was truly "free" you could have hackers finding a way to allow tethering, or turning on the features the telecos killed, and they certainly wouldn't like that. With something like PMPs I can see having freedom because other than Apple's walled garden of iTunes most manufacturers don't care what you do with the device once they have your money, as long as they don't have to support your hacks. But the telecos want to keep getting your money by forcing you to buy "premium features" which are often already on the phone and simply turned off. And I really don't see them giving up that golden goose for users freedom any time soon. So really, what good would having the GPU open really be if the rest of the device is locked tighter than a nun's thighs?

Re:This is the great thing about Android.

[marcansoft]

I have no problem with both open and closed source softwre. I have an Nvidia graphics card and use their binblob drivers. As long as you trust the manufacturer to deliver quality drivers, there's no problem with that. The issue arises when people try to mix together open and closed software in order to reap the benefits of open source without giving anything practical in return.

In this case, Qualcomm are trying to avoid the mess of maintaining binary kernel drivers, while not actually providing an open source driver for their hardware. This shouldn't fly. They can either deal with kernel maintenance and binary modules themselves, or open their entire driver so the open source community can hack it, improve it, and get into a state where it can be merged into the kernel.

If this "open source" driver were merged into the kernel, it would still be tied to the closed source usermode binblob. That means the ioctl intervace is untouchable, which means pretty much nothing can be fixed (as far as the interface goes) without Qualcomm's cooperation. It also means that kernel developers have to trust the binblob, and the lack of specs also means that the behavior of the kernel drivers (e.g. their security) cannot be reasonably analyzed. This isn't good.

In fact, Nvidia have open sourced small portions of their drivers (the settings GUI and part of their kernel abstraction shim, at least), but they are maintaining these themselves. Really, there's no problem with partially open source drivers, you just can't expect open source developers to maintain the open source part for you.

Re:This is the great thing about Android.

[xonicx]

Nvidia tegra already has all kernel component open sourced. Qualcom does not want to loose open source fans. http://nv-tegra.nvidia.com/gitweb/

Re:This is the great thing about Android.

[Anonymous Coward]

OK I'll buy Snapdragon smartbooks then.

Re:This is the great thing about Android.

[SimonTheSoundMan]

Fresh Off the Slave Ship?

Re:This is the great thing about Android.

[fuzzyfuzzyfungus]

The less polite; but not substantially less accurate, version of TFA's headline might be "Qualcomm Maker attempts to pass off responsibility for kernel-mode portion of 3D Snapdragon driver"...

Re:This is the great thing about Android.

[hairyfeet]

Good points and I can see why developers wouldn't want this driver. But since you have Nvidia I have a question: Why not ATI? Isn't one of the points FLOSS users have been pushing for years "Open up your specs and we'll support you"? Here is a company that has done exactly what the community asked them to do yet time and time again we see guys here at /. pushing Nvidia for Linux. Do FLOSS developers just suck for graphics drivers?

Because it seems to me if Linux users actually want companies to do as they ask and open up their specs they would actually buy the products and show that Linux support equals better sales, thus hopefully getting more companies to release. It seems to me more than a little bit hypocritical (not you personally, the community) to ask companies to release specs and then when one of the big ones do to push the rival GPU that doesn't release squat.

Re:This is the great thing about Android.

[marcansoft]

I'm using a laptop, so my choice of graphics chipsets is limited (though this one does use an MXM card, so I can conceivably switch it for another card at some point in the future).

Currently, the big feature that Nvidia has that ATI open source drivers lack is hardware video decode acceleration. As far as I know, ATI hasn't released specs for that part of their chips. I enjoy being able to play 1080p H.264 videos with little CPU usage (heck, even with a reasonably modern Core 2 Duo, you just cannot play some high-bitrate videos without hardware help). Whenever this shows up in the open source drivers I'll definitely give ATI a serious chance.

Re:This is the great thing about Android.

[Svartalf]

The driver stack for the FOSS side is just now beginning to learn how to crawl properly- something you need to do before you can walk or run.

Previously, we'd reverse engineered the stuff. Based on what I've learned doing work for one of the Big Two (that'd be AMD or NVidia...), they're barking up the right tree, doing things in the large the same way they do things within the driver. When the community gets to those first few stumbling steps instead of crawling around, the speed of development will increase- and AMD's stuff will suddenly become quite valuable to anyone on Linux or other FOSS OS.

Like we've been told before in the past- doing 3D drivers isn't exactly an easy thing to do. It takes some time before you can get to the same level of support we see with the proprietary drivers from NVidia and AMD. Unfortunately, you either have to choose pretty robust drivers, slightly less robust/speedy hardware, coupled with closed drivers- or choose much more unstable drivers (some people have GREAT results with AMD's stuff, I've got decent results with some issues in my case- but some have pure HELL with the drivers in question...) and the promise of 6-12 months down the line having 60% of the peak performance with an open source driver, coupled with the promise of seeing as much as 85% of the peak performance or more in another 12-24.

Many will choose the shiny solution that works right now. Some don't need and can't afford to fidget with the hardware to make it work and will buy something for business that will work right now (AMD's stuff is less robust in the laptop space until recently- which translated into an NVidia purchase on my i7 laptop I'd bought a while back.

If AMD's closed source solution was a full-on winner (it's not...) there'd be a lot less people buying NVidia right now because they opened up and it's coming together for everyone on that space, albeit slowly.

Re:This is the great thing about Android.

[Hatta]

As long as you trust the manufacturer to deliver quality drivers, there's no problem with that.

The problem comes when they don't. We've been waiting for Xrandr 1.2 support from Nvidia for 3 years. Everyone else has it by now, but Nvidia users are out of luck. So if you want independent rotation of monitors under one X display without breaking acceleration, you can't do that with nvidia.

Re:This is the great thing about Android.

[Anonymous Coward]

Feces On Sweaty Scrotum?

Re:This is the great thing about Android.

[WNight]

You are not even merely a citizen of Texas, Texas is a state of people like you.

Re:This is the great thing about Android.

[Zixaphir]

As much as I love AMD (OMG, FUSION!! FUCK FUCK FUCK FUCK FUCK)... AMD/ATI video cards suck for anything that isn't DirectX. As much as they push their specs and let the FLOSS community develop drivers, it doesn't change the fact that OpenGL isn't something that AMD develops the hardware of their cards for. We can optimize the software all we want, but compared to nVidia cards, ATI is terrible for anything that isn't DirectX. So you have the software end of AMD doing one thing to support the open standard, and the hardware end fabricating cards almost exclusively for DirectX.

Re:This is the great thing about Android.

[badkarmadayaccount]

Would it be wise for the Galium3D devs to create a raw D3D state tracker? Pull a triple-E on microsoft with some crazy features that would require them to rip apart NT in five dimensions before thinking of implementing them.

Re:This is the great thing about Android.

[Svartalf]

And I'm sure where you live is a State full of people just like you...

You went out of your way to accost someone for their Sig- which is a statement of the fact that I choose to claim and use my sovereignty as opposed to being a good little sheeple and being a source of money for those people that claim to be our leaders and those of business. I did nothing, nor stated anything remotely inflammatory, past that sig that might have even merited the response you made- especially not in my post you responded to. I'm still quite a bit at a loss as to why you singled me out for such a verbal assault- but then this is /., where there seems to be no end of poo flinging monkeys to abuse and amuse you.

Re:This is the great thing about Android.

[WNight]

Sigh. No.

I mean that you are more than an anything of Texas, Texas is defined in terms of you, the people. Even citizen is a fairly passive term compared to sovereign for instance.

That said, if I did find your sig inflammatory I would not hesitate to attack it despite you having been discussing something else. If I have to look at it, I'll feel free to respond.

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

[GNUALMAFUERTE]

Where they stand, and the power they have right now.

FTFA:

We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd like
to clarify my position once so they don't all come asking the same
questions.

I hope they use this new found power wisely.

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.

Compiz

[WarJolt]

If I can't use it with compiz it's not really worth much to me. I've been waiting years for DRI2 on ATI. I'll never buy ATI again. Snapdragon processors could be used for netbooks. I don't think it will make it until they learn the open source community will probably help to get compiz running on it if they make it available.

Re:Compiz

[MostAwesomeDude]

So many possible replies, so little time.

"Sorry. I didn't know that it was our fault that your distro of choice didn't pick up DRI2 sooner."

"Well, if you ran Fedora, this wouldn't be a problem."

"Why DRI2? DRI1 is just fine for compiz, as long as your server supports AIGLX, or even *shudder* Xgl."

"Well, obviously you won't buy ATI again; it's AMD now."

">implying ARM processor manufacturers ever release 3D code or specs"

"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"

"So I know this is gonna kill my karma, but..."

Re:Compiz

[drinkypoo]

So many possible replies, so little time.

Too bad all of them are stupid.

"Sorry. I didn't know that it was our fault that your distro of choice didn't pick up DRI2 sooner."
"Well, if you ran Fedora, this wouldn't be a problem."

If you ran Fedora, you'd be alpha-testing features included in the OS when it is KNOWN they are not ready for prime time, but included anyway since Fedora is the alpha test environment for RHEL. Some of us are not willing to do this. I was a loyal RedHat user until RedHat went away, so I'm not saying this out of rpm allergy (although now that I've switched, I'm never going back.)

"Why DRI2? DRI1 is just fine for compiz, as long as your server supports AIGLX, or even *shudder* Xgl."

Did you ever use Xgl? First of all, it's over. Second, it worked better than AIGLX does. I got better performance on Compiz window transformations, for example.

"Well, obviously you won't buy ATI again; it's AMD now."

The video cards still say ATI on them. This is very helpful, because it tells me which cards to never buy.

"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"

I've run Blender maybe twice and I will never play WoW. But I use Compiz features not just every day, but every hour. Expose and Shrink Windows are tied to hot corners and I use one or the other almost every time I switch windows.

"So I know this is gonna kill my karma, but..."

If only.

Re:Compiz

[ppz003]

If you ran Fedora, you'd be alpha-testing features included in the OS when it is KNOWN they are not ready for prime time, but included anyway since Fedora is the alpha test environment for RHEL. Some of us are not willing to do this. I was a loyal RedHat user until RedHat went away, so I'm not saying this out of rpm allergy (although now that I've switched, I'm never going back.)

You know, just about any modern distro has this now. Ubuntu, Arch, hell, even Slackware supports DRI2 for ATI out of the box now.

I've run Blender maybe twice and I will never play WoW. But I use Compiz features not just every day, but every hour. Expose and Shrink Windows are tied to hot corners and I use one or the other almost every time I switch windows.

Yeah, I bet you do spin the cube for hours at a time. You so l33t.

"So I know this is gonna kill my karma, but..."

If only.

Given who the GP is, I'm sure he has plenty of karma to burn. I might just have to find his posts and give him some more for making DRI2 and 3D work on my AMD/ATI card in the first place.

Re:Compiz

[TheRaven64]

"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"

Not necessarily Compiz, but a compositing manager lets you offload a lot of work to the GPU and improves power consumption. In X11 using the core protocol, moving a window requires all of the windows that are exposed by the operation to redraw the exposed portion. On a mobile device, this is burning CPU cycles (and therefore battery) for something that is just duplicating work. In contrast, with a compositing manager running the app only needs to redraw when something changes. The resulting window is stored as a texture. When you move one window, the GPU just composites them again. This takes a lot less battery power than redrawing. If the apps are drawing a lot of text, using XRender does all of the antialiasing on the GPU too, which reduces power consumption as well (rendering antialiased text on the CPU is insanely processor intensive, when you consider than text output was something computers were doing decades before the first GUI).

Re:Compiz

[drinkypoo]

You know, just about any modern distro has this now. Ubuntu, Arch, hell, even Slackware supports DRI2 for ATI out of the box now.

So what you're saying is that it was an even dumber thing to say than I thought? Thanks!

Yeah, I bet you do spin the cube for hours at a time. You so l33t.

I don't use the cube, since its contents haven't been clearly visible on a fast flip since Xgl died and a slow flip is stupid. I use the wall. Expose and Scale Windows are both useful, unlike the cube. But go ahead and make pointless attacks.

Given who the GP is, I'm sure he has plenty of karma to burn. I might just have to find his posts and give him some more for making DRI2 and 3D work on my AMD/ATI card in the first place.

Now if only he could make the drivers not suck.

Re:Compiz

[MostAwesomeDude]

Now if only he could make the drivers not suck.

Bug number, please. I'm not CC'd to all ATI bugs, just ones pointed to me or assigned to the DDX. Or did you just want to attack me again?

Re:Compiz

[MostAwesomeDude]

"Really? Compiz? Your killer app is compiz? Not Blender or WoW?"

Not necessarily Compiz, but a compositing manager lets you offload a lot of work to the GPU and improves power consumption. In X11 using the core protocol, moving a window requires all of the windows that are exposed by the operation to redraw the exposed portion. On a mobile device, this is burning CPU cycles (and therefore battery) for something that is just duplicating work. In contrast, with a compositing manager running the app only needs to redraw when something changes. The resulting window is stored as a texture. When you move one window, the GPU just composites them again. This takes a lot less battery power than redrawing. If the apps are drawing a lot of text, using XRender does all of the antialiasing on the GPU too, which reduces power consumption as well (rendering antialiased text on the CPU is insanely processor intensive, when you consider than text output was something computers were doing decades before the first GUI).

Sure, although even non-compositing WMs still offload most blitting ops to the GPU, due to the way Xorg accelerates operations. Also, if the Composite extension is present, you can do server-side compositing, which does the same snazzy window ordering without any effects or WM help.

In terms of power savings, it's not about saving CPU time as much as it is about GPU utilization, since the GPU will drink battery even when idling. The biggest battery gains we've been making aren't from extra GPU usage, but from getting the GPUs to turn down so they aren't always running full-tilt.

Re:Compiz

[drinkypoo]

Bug number, please. I'm not CC'd to all ATI bugs, just ones pointed to me or assigned to the DDX. Or did you just want to attack me again?

I meant it more as an attack on AMD/ATI in general. I've been reluctantly using AMD video chips in a variety of contexts since the Mach32 and have had driver-related woes with all of them. There is literally no ATI video solution I have EVER used that didn't cause me some kind of problem, and always clearly related to the functioning of the driver.

My latest problem with ATI graphics is failure of the R2xx video in the R690M chipset to produce video with the 'ati' driver without trashing. It mostly trashes on scroll, it does it more if I have more windows open (more memory used?) and it still trashes if RenderAccel is disabled. This experience has actually put me off of AMD somewhat, because not only can I not use the graphics reliably under Linux in spite of the GPU core being an antique, but AMD didn't bother to contribute power saving feature support for the Linux kernel. Consequently my "netbook" (subnotebook really) which gets 5 hours under Windows gets about 2.5 under Linux. That's not ATI's fault though, except that AMD and ATI are now one company. The system also crashes on suspend under Windows 7, but it does that on Linux, too. This is clearly a video driver problem (at least on Windows) because it doesn't happen on the VGA driver. This CPU (Athlon L110) and chipset were both brought to the market in consumer devices after the announcement of Windows 7, but AMD never bothered to release any Windows 7 driver downloads for it (until recently, when an outdated video driver showed up) so it's still ticking along on old drivers... but not well.

Every time I've bought and AMD card I've suffered. Every time I've tried to use Linux with ATI graphics I've suffered even more. nVidia may be a bunch of bastards, but their cards work, so long as you don't buy the latest and greatest and try to use it with Linux. That's even more of a recipe for disaster with ATI, however.

FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!!!

[Anonymous Coward]

What is it with these ME-TOO asswipe corporations that show the tits but keep the pussy behind a chastity belt?

Re:FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!

[oldhack]

The foul-mouthed AC seems to have hit the nail on the head. Mod the bugger up, interesting, troll, or whatever.

This is for you RIM, Nokia, Microsoft and Apple

[bogaboga]

Companies including RIM, Nokia, Microsoft and Apple should watch out for Android with its Linux roots. Development appears to be fast. At this speed their lunch is at risk.

What appears to be holding Adroid is "bad" publicity on battery life, the poor organization of the Android Market including poor quality apps and the [subjective] poor user experience on high end phones.

As a matter of fact, the state of the Android Market is severely anaemic because whereas apps in this market are said to number about 75,000 now, having a look over here does not show any figure near that!

To make matters worse, there is no provision for searching for an app whose name you might not remember well. What surprises me is that the market is owned by a company (Google) which boasts of the greatest and best search engine in planet earth! Think about that for a moment.

Now before I get flamed, I know there is AndroLib. What I am talking about are efforts by the search giant Google.

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

[Microlith]

Companies including RIM, Nokia, Microsoft and Apple should watch out for Android with its Linux roots. Development appears to be fast. At this speed their lunch is at risk.

RIM and Microsoft are the ones who really have to be concerned. Apple will turn into a niche, though a very competitive one. Nokia however is pushing Symbian down the stack to their midrange and lower phones, reserving the high end for MeeGo, which holds to more "true Linux roots" than Android by being a common Linux stack from the kernel up through X.

That doesn't mean it's competitive, but it sure gives it one hell of a draw that many people lost once they realized Android was a Java-incompatible Java sandbox.

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

[Clarious]

Nokia only intends to use Meego for N series, which is multimedia oriented, while the E series, aimed at business user (high end) still use Symbian.

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

[Anonymous Coward]

To my knowledge, Nokia has stated that they plan to adopt Meego on all of their future N series devices, but this statement doesn't imply that other series would stay exclusively Symbian/S40/S30 (or whatever it should be called). I have little doubt E series couldn't move to Meego if Qt transition is executed successfully - after that, most of the recent applications would be source-compatible between Symbian^4 and Meego anyway.

Although couple years seem like a long time in mobile software sector, one also has to notice that expected useful lifespan of a specific binary application package is much shorter in mobile space, and these kinds of transitions are easier than in desktop space where companies may be stuck using same binary applications for even decades.

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

[Anonymous Coward]

I have little doubt E series couldn't move to Meego if Qt transition is executed successfully - after that, most of the recent applications should by that time be source-compatible between Symbian^4 and Meego anyway.

That's what I meant.

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

[AHuxley]

Whats holding back Android is Googles ability to "Bezos" away any app they dont like.
With Apple you spin the acceptance wheel, with Google's vision of computing you will always have that doubt that one day your app might be gone.
The rest are what parents and grandparents are tied to by their profession.
What would be nice is a Linux desktop in your hand, free to code on and see the hardware, flip it over and you have a packet pushing networked phone. Linked by a data network you pay for, not legal teams looking down at your mobile desktop.
Closed is great if you have to use it or get it for work, but we seem to have a real effort to trap developers in an almost free until you read the fine print walled gardens.

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

[VValdo]

And don't forget Cyrket.

W

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

[victorhooi]

heya,

Actually, another thing might be the general shonky level of hardware...lol...

And it's not "bad" publicity on battery life. It's a known problem. I assume here you mean the Nexus One, Google's flagship Android phone.

As are the issues with touchscreen going out of calibration, and the 3G reception issues.

And the Motorola Droid has had it's series of hardware issues/quirks.

I've gone through two Nexuses - first one had an issue with the camera failing. The second, the GPS radio seems to have failed. And HTC support is a nightmare to deal with, and Google is surprisingly unhelpful. Say what you will about Apple about shonky closed gardens and price gouging, but at least their support is usually good, and they'll bend over backwards to help you (sister has Macbooks, I've had iPods).

Cheers,
Victor

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:This is for you RIM, Nokia, Microsoft and Apple

[valentingalea]

I have an HTC Desire - which is pretty much the highest end phone right now - and the user experience is nowhere near poor - where did you get that?
I worked for Gameloft on IPhones all day and I know what I'm talking about :P

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

[Anonymous Coward]

As usual: Nokia did it first but another company gets the credit.

In case you haven't noticed, the kernel part of the PowerVR SGX driver the N900 is fully open source -- the user space bits aren't.

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

[drinkypoo]

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.

Please provide a link to a place where I can download symbian sources, build them, and upload them to a phone before you say anything this ridiculous again. "Not all of the code is yet available under open source licences". PURE FUD. STOP NOW.

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

You can use all those languages on Android as well via the NDK, but if you want a GUI you will have to touch Java.

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

[mdwh2]

http://developer.symbian.org/main/source/license/index.php says it's the tools code that currently isn't available, though I'm not sure what that specifically refers to. Also note from http://developer.symbian.org/wiki/index.php/Platform_Completeness :

"However, some technologies which were historically included in Symbian OS / S60 platform releases were distributed under specific commercial licenses and hence could not be included in the initial Symbian Foundation codebase. Essentially Nokia have contributed everything they can to the Symbian Foundation but some technologies are licensed from other companies and hence can't be included in the platform until discussions with those companies have been completed."

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

[mdwh2]

What would be nice is a Linux desktop in your hand, free to code on and see the hardware, flip it over and you have a packet pushing networked phone. Linked by a data network you pay for, not legal teams looking down at your mobile desktop.
Closed is great if you have to use it or get it for work, but we seem to have a real effort to trap developers in an almost free until you read the fine print walled gardens.

N900?

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

[drinkypoo]

Essentially Nokia have contributed everything they can to the Symbian Foundation but some technologies are licensed from other companies and hence can't be included in the platform until discussions with those companies have been completed."

Yes, or in other words, portions of Symbian are closed and likely to remain so until Symbian is completely over. And since Symbian has been relegated to basement status (it will never be on another flagship phone made by any manufacturer anywhere anywhen) it is largely irrelevant anyway. The point remains that Android or perhaps MeeGo is the freest phone OS available, and Symbian is trailing well behind.

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

[dwater]

Ok, I admit, I haven't tried.

> Please provide a link to a place where I can download symbian sources, build them,
> and upload them to a phone before you say anything this ridiculous again. "Not all
> of the code is yet available under open source licences". PURE FUD. STOP NOW.

However, I followed your link and one link deeper I find :

"Why haven't you made everything public?

Most of our code and tools code was originally contributed under the SFL. On 4th February 2010 we made all of our source code open source, however some tools code was not ready.

We promised to make all of our code available under the EPL by mid 2010. We made our source code available as soon as possible and hope to complete the full process ahead of schedule. We'll continue to publish information on Platform Completeness.
"

I guess it's debatable, but I would say that not including source code for some tools does not count as 'not open source' - it totally depends on what those tools are. I imagine there are tools Google use that aren't Open Source.

So, I stand by my interpretation.

IINM, the code is here :

http://developer.symbian.org/wiki/index.php/Making_Changes_with_Mercurial

I'm not quite sure what is missing and how it effects the ability to build it.

I don't have a link to where you can upload them to a phone...I'm not even sure what that means. I suppose you mean just instructions on how to do so. While relevant in the grand scheme of things, I don't see how that is a problem Symbian should be solving. What is the equivalent for Android? I suppose now Google have produced the Nexus one, they give instructions on uploading to or flashing that.

> You can use all those languages on Android as well via the NDK, but if you want a GUI you will have to touch Java.

We agree on that then. I've not tried GUI development on the new Symbian platform, only the previous S60 2nd and 3rd, and then only in Symbian C++, so I can't really speak to how accessible GUI development if you happen to choose those other languages.

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

[jedidiah]

> Whats holding back Android is Googles ability to "Bezos" away any app they dont like.
> With Apple you spin the acceptance wheel, with Google's vision of computing you will always have that doubt that one day your app might be gone.

Apples have the same problem.

Unless the user is in control of the device, this is a problem across the board.

It's not unique to Google (or Amazon).

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

[dwater]

Now *that* sounds like fud to me.

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

[badkarmadayaccount]

Not really certain - if someone ports the pvops framework to symbian, we could have the best of both worlds - linux and symbian. And symbian is still better at handling low resource real time devices. Sorry, Tux, I love you, but it's true.

Re:FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!

[Anonymous Coward]

+5 troll?

EGL and OpenGL ES

[Anonymous Coward]

Compiz does not use EGL (it uses GLX) nor is it written to work with GLES. It could be ported but they haven't done the legwork for it yet.

There are some simple X11 compositors for EGL+GLES. usually just alpha, window shadows and a couple hard-coded special effects. I've worked on one for the Tegra2 and it wasn't all that hard to write. EGL is superior to GLX as an API (but there are a couple annoying quirks) although the official docs for EGL suck when it comes to X11 specific extensions (EGL is part of OpenKODE and works on things other than X11, so doing things like rendering to a server pixmap is not well documented, but it does work).

Re:FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!

[Anonymous Coward]

+i: Insightful troll

Brilliant move

[Weaselmancer]

Well, halfway anyways. Release the other half (the user space) part as FOSS and you'll be golden.

The biggest problem I've seen in embedded Linux is poor graphics performance. You have all this video acceleration that CE/XPe can take advantage of, and Linux doesn't get but a mere teaspoon of the graphics speed the hardware is capable of.

You really want to see your platform take off? Want your CPU sales to go through the roof? Give us something that is as accelerated as the Microsoft side of the equation. Give us the source. It won't hurt your sales. It won't help your competitors. Reverse engineering would take more time than actual R&D. Who wants to copy a video device that's already on the market when you can make better and faster by the next quarter anyways?

Seriously - this is the way to go. Release your driver source. All it can do is help move your product into more market spaces.

Re:Brilliant move

[gbjbaanb]

Its not necessarily the way to go - sure its probably the best way, but since when has that ever been a factor in human endeavours.

Let the hardware companies that they can keep their binary-only drivers, but they'll be maintaining them themselves. If the ABI was stable, chances are they'd be perfectly happy with this too. Linux would get hardware accelerated drivers, you might have to download them yourself from the manufacturer website, but otherwise all would be goodness.

Current status is a bit of a stand-off that no-one wins. The hardware companies don't want to release their very precious secret driver code, the kernel guys don't want to fix the driver interface, the consumer doesn't get fast hardware acceleration, and Steve and Steve laugh their heads off as users stick with Windows and Macs. Make it easy for the manufacturers to support their systems and they will, and they'll drive more people to using them. At the moment, all we have is Linux based systems that are 'consumer devices', ie closed off ecosystems with fixed hardware support (and no, an oss driver won't sell more graphics chips, they're already chosen from features and price, driver support is almost a non-factor).

This is one battle I think the OSS guys have to 'lose' in order to win. We're never going to get the best backing from hardware companies if we force them to release their driver code (not the important stuff, your webcam driver can go fly, but your 'competitive advantage' video driver is another matter), instead we need to make it easy for them to support Linux with their binary drivers, easy to download and install.

Re:Brilliant move

[Ginger Unicorn]

I thought the reason 3D drivers weren't open sourced was because of Patent/Licensing agreements that forbid it. As I understand it, AMD are open sourcing their drivers, but carefully bit by bit, in order to avoid releasing bits that other companies hold the rights to.

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:Command stream protocol?

[Anonymous Coward]

I don't understand either why they don't open up chip-level communications. I mean, their stuff should be patented, right? So it should be documented already in the form of patents.

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.

Re:Command stream protocol?

[Anonymous Coward]

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!

Open source the d...d thing.

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 still hasn't released kernel source after a month of distributing the binary kernel. Despite the fact that GPLv2 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 (other than AT&T) has no respect for the GPL and has reduced developers to reverse engineering Linux kernel sources, asking clueless customer service reps for a source release, and generally trying everything they can think of without getting any positive results at all.

Re:FUCK THEM MAN FUCK THEM TO TEARS ALREADY !!!!!!

[Anonymous Coward]

It's been known to happen, e.g.

http://interviews.slashdot.org/comments.pl?sid=63874&cid=5938340

MOD PARENT UP!!

[Anonymous Coward]

MOD PARENT UP!!

Correction

[EEPROMS]

Qualcom have released "some" open source 3D driver code, yes folks there is a lot of code missing or obfuscated by proprietary libs . The qualcom snapdragon cpu isnt much better either. After the FOSS community having to deal with Qualcoms shenanigans I can understand why Apple bought it's own arm design house and is now getting samsung to fab a CPU for the iPhone and iPAD called the A4. Why put up with all the qualcom crap that android devs/device makers are putting up with when you can stick your middle finger up and make your own CPU. There is an upside though, Intel is porting Android to X86 so we may get some nice Atom cpu tablets on the market soon without all the stupidity that qualcom and its lawyers are introducing.

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

[Anonymous Coward]

The nexus one kernel source was available from android.git.kernel.org the day the phone became available for sale.

Dave not under "Red Hat mind-control"

[xiando]

Dave Airlie denies being under Red Hat mind-control in http://lists.freedesktop.org/archives/dri-devel/2010-July/001855.html It's good to see that the Red Hat drones working on the kernel are allowed (or atleast claim) to be kernel developers first and corporate slaves second.

Re:Dave not under "Red Hat mind-control"

[AdamWill]

In this case, we (RH) don't even really need to be that Good. (Of course, we are - the sun shines out of our ass, etc etc). But in this particular case, as Dave says, RH - corporately - doesn't really care. RH doesn't have a horse in the race, when it comes to graphics on cellphones, after all.

Plenty of people at RH - mostly those of us who are stuck with crappy graphics adapters in our laptops / cellphones... - care about the issue, but RH as a company doesn't really give a rat's ass.