If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

The current best supported (although still not open source) graphics driver for ARM SoC's has got to be the Adreno series. Qualcomm is very good at getting new and updated drivers out for the adreno hardware. That includes drivers supporting the latest versions of Android for hardware that was never and will never get updates from the manufacturers. For example, Adreno 200 (Nexus 1, etc., none of which got updated past Android 2.3) -- the latest Adreno 2xx driver will happily run an Adreno 200 on Android 4.1.2, and as a result, this old hardware runs the latest version of Android with full function and full acceleration.

It is worth noting that Adreno shares common roots with Radeon, which makes sense since Qualcomm acquired it from AMD (formerly called "Imageon"). The name itself emphasizes this fact since Adreno is an anagram of Radeon, and, in fact, the Adreno 200 is nothing other than an AMD Radeon Z430. In fact, the freedreno project is using a lot of the Radeon documentation to push the freedreno driver forward. The big question I have, is why doesn't Qualcomm contribute to this, since AMD's already done the majority of the hard work in freeing up the IP..?

Albeit no ARM, it seems valleyview SoC might be the first android runing SoC to have a GPU suported by OSS drivers. Being owner of a motorola atrix, i have learned my lesson, my next phone must have proper oss drivers.

Since you develop android roms, can you tell if there is any other SoC component besides the GPU which requires closed drivers?

Can you also kindly explain why does each device needs its own kernel?

I link to myself. I build my own AOSP for my own hardware. I don't care for the CM crap, they take AOSP, bastardize it, break almost everything, and call it their own, all while taking for-absolutely-fucking-ever to actually do it.

Well if they break things so horrendously, maybe you should give them a hand? As far as I know, CM is still a community.

I can't understand why can't google require that in order to use the android brand, device manufacturers would have to mainline any code required in a google branch so that the updates come from google instead of these lazy greedy oems. This should probably make getting the newer android version working easier for the AOSP than it is right now right? And anything helping the android fragmentation should be good for google right? What is it that I'm missing?

I link to myself. I build my own AOSP for my own hardware. I don't care for the CM crap, they take AOSP, bastardize it, break almost everything, and call it their own, all while taking for-absolutely-fucking-ever to actually do it.

Monthly releases are "for-absolutely-fucking-ever?" Over 2.5 million people use CyanogenMod. Do you honestly think they "break almost everything"?
You say CyanogenMod "bastardizes" AOSP, but it is really fairly close to AOSP. There are some added options to allow users to customize their device but they keep it down to a reasonable and usable amount. Beyond this, the primary changes to AOSP are for compatibility of the 100+ devices that CyanogenMod supports. CyanogenMod supports almost every major SoC architecture in one code base and it honestly does it very well, this is something that neither Google or the major OEMs do.
It is great that you build AOSP for your devices but don't act like CyanogenMod and others do nothing of value for the community.

Back to what was originally brought up about CyanogenMod, I don't think Samsung is releasing more source code *just* because of CyanogenMod or other 3rd party distributions of Android. That said, I do think Samsung at least cares about that community to some degree because they made this announcement at a small Android enthusiast conference made up largely of AOSP hackers. In addition, Samsung has also been making a concerted effort to reach out to AOSP hackers through forums and other means. At the end of the day Samsung is really just getting up to the standard of what TI and Qualcomm do with OMAPZoom and Code Aurora respectively.

I could definitely see this being useful in a hypothetical Chromebook CM10/11, and if Android on netbooks turns out to make sense, enthusiasts can get another taste of the future (much like the Nook Color + CM7 hinted at the Nexus 7, i.e. an affordable real android tablet, a year later)

The upside of 'fragmentation' is that such avenues can be explored... unlike, say, being completely unable to port Windows on ARM to one of those little Chinese stick computers. A $100-150 one with Windows and Office might've just saved the Windows desktop from seeming irrelevant, but we'll probably never know.

Can you also kindly explain why does each device needs its own kernel?

Because ARM CPUs aren't standardized like x86 is. Each requires a different initialization routine to boot. There's been some recent work in the linux kernel to allow consolidating all these different ARM architectures together, but it is brand new and hasn't migrated over into android yet.

Albeit no ARM, it seems valleyview SoC might be the first android runing SoC to have a GPU suported by OSS drivers. Being owner of a motorola atrix, i have learned my lesson, my next phone must have proper oss drivers.

Since you develop android roms, can you tell if there is any other SoC component besides the GPU which requires closed drivers?

Can you also kindly explain why does each device needs its own kernel?