Shared publicly  - 
The Saga of a CyanogenMod Exynos4 device maintainer - Samsung, the Hope-Killer

Disclaimer:  This series of posts contains the personal opinion/perspective of just one member of the team.  It is not, in any way, an official statement from the project.

This is a continuation of the saga, with the last installment being

So, on Monday after the BABBQ, I flew home (FAIL on my part - 9 AM flight on a Monday.  I am NOT doing THAT again.  I had to go to bed early Sunday evening because of that failure to properly choose flights.)

As documented in the previous post, I flew back hopeful that things would finally improve with Samsung.

Only a few days after, +Daniel Hillenbrand emailed our Samsung contact with some questions related to Galaxy Tab 2 call audio.  Specifically, Bluetooth calls on these devices become silent after a few seconds in AOSP, with the RIL popping out an unknown unsol response and also an "am" intent:

E/RILJ    (  533): Exception processing unsol response: 11022Exception:java.lang.RuntimeException: Unrecognized unsol response: 11022
D/RILJ    (  533): [UNSL]< RIL_UNSOL_AM broadcast -a android.intent.action.pcmclkctrl --ez status true
D/RILJ    (  533): Executing AM: broadcast -a android.intent.action.pcmclkctrl --ez status true

(Remember my "spoiler alert" at - here's where it's important)

Within four hours, he received a response of "we can't/won't help you.  contact Wolfson".  Huh?  Wolfson?  For a RIL issue, and an issue not seen on any other Wolfson-audio-enabled device?

So, just after promising to be more open and helpful to developers, Samsung was being faster than ever with the "no, no help for you" responses.  Daniel lost hope at this point, and I lost most of the hope I had gained at BABBQ after hearing about this too.

A few days later, we saw the Insignal code repositories at open up.  On Thursday, someone sent me a message on gtalk indicating that code had just been pushed to

YES!!!  New code!  Well...  not really.  While it had a few new things (LPA audio, some additional HDMI bits), it still exhibited ALL of the problems that the old Insignal reference source and the Hardkernel reference source did.  In short, it was completely useless on 99% of the Exynos4 devices in the world for reasons none of us had been able to figure out for the past six months.

A waiting game started, where we hoped we would see an update to this code.  We saw code pushed to the other platform repos, but it was nothing we didn't already have/weren't already using.

Eventually, the "about" page was updated - - It was very explicit that only Exynos 4412 devices were receiving ICS reference source...  Dafuq?  While working 4412 sources should easily have been backportable to 4210, the fact was, other manufacturers weren't EOLing their SoCs so rapidly.  In addition, at this point, Jellybean was pushed for Exynos5 devices.  Conspiciously missing from these Jellybean repositories was ANY signs of Exynos4 support, in addition to the fact that Exynos4 was explicitly called out as only being supported by ICS in the sources.

Similarly, was published with no discussion whatsoever of Jellybean on Exynos4 - despite the fact that at that point, Jellybean had been available on Exynos4 handsets for over a month and a half.  So "the code doesn't exist" isn't an excuse here - it clearly exists on the I9300 and N7100!

In addition, the schedule is interesting in that they could code everything "green" and not deliver the items (such as working functional HWC and not the compiles-but-does-nothing placebo they've published so far) that got them into this mess in the first place.  As far as graphics subsystem support goes, their definition of success is "boots to lock screen" - SERIOUSLY?  Almost anyone, even winzip kangbangers, can get a device to boot to the lock screen.  That doesn't mean the device's graphics subsystem will be remotely functional/usable.  HWC could be completely missing and they could still claim "green/done" on that schedule.

In addition, SamsungExynos on Twitter is now linking to Insignal saying "the sources are here" - indicating they consider that the useless cruft they've pushed out fulfills their promises to the community.

Last but not least, Jellybean on Exynos4 is "out of plan" for Samsung, despite the fact that I9300 has had Jellybean for over a month and a half - - "I'm sorry to say JB version for Exynos4 is out of plan until now, as I know."

So, at this point, I've basically lost all hope.  While I have a few things I was going to ask the people I met at BABBQ, after seeing how quickly they responded with "no we won't help you" to Daniel just after BABBQ, it's not worth my time even writing the email...

All of this has just been yet another case of Samsung talking and making promises and failing to deliver, just like they've been talking and making promises for over a year.  Development boards are supposed to be AHEAD of handsets - they don't need to deal with carrier testing, wireless certifications, or any of the things that are usually notorious for holding back handset updates.  Plus their intended target is DEVELOPERS, so they should be the "bleeding edge".  This is what Qualcomm and TI reference source is - It's the absolute latest, ahead of anything seen on handsets.  What we're getting from Samsung is more than 6 months out of date - ICS for an SoC that was in a handset which launched with ICS in Spring 2012, and which received an official Jellybean update (carrier approvals/wireless certs and all) in early October 2012...  But they're still working on ICS for their reference source???

The next post in the saga will be the conclusion, summarizing where I stand/how I feel after all this crap I've dealt with, and what I know of where some of the other Exynos4 maintainers stand.

The conclusion is posted at
Achwaq Khalid's profile photoWilliam Puckering's profile photoAndrew Dodd's profile photoZé Belchior's profile photo
Thank you for documenting all this, this is why I do want to get away from samsung unless I know they'll change 
This is really sad. It flies in the face of openness, for no obvious reason. Actually, the only reason to withhold source code would be to slow down competitors. In your opinion, is this effective (disregarding all moral implications)? Would it help Qualcomm to have good Exynos4 sources? Just wondering. 
+Marciano Siniscalchi No, Qualcomm has their own totally different graphics subsystem, and looking at their HWC source, and all reports of how it performs, the CodeAurora HWC is unambiguously superior to anything that has been delivered on Exynos4, whether in reference source or binary.
Thanks entropy512...or Andrew? Either way I'm voting with my friends and my familys wallets. And they are going Sony/Nexus/Asus. A very small insignificant money drop in Samsungs pool of cash. But I hope it spreads so they learn their lesson as Sony did.
Please don't flame me for asking this, but is it possible that the source code Samsung has provided does work, but you guys are missing some key element to get it running, or something in addition they haven't provided to complement it? I don't see why they would commit fake or unusable code, they must be using it in consumer devices as we speak. I guess the question is, what do they still have that they're not sharing that you need? Anything identifiable?
There's a possibility that the code sort-of works on OrigenBoard.  However, 99% of LSI's devices do NOT go into OrigenBoards - they go into other devices.  As I've discussed previously, there are clear similarities in behavior between the hwcomposer implementations of the Meizu MX and Samsung Mobile's devices.  That indicates a common source code heritage (LSI).

There's a slight chance it might be possible, by ripping everything out and replacing it, to get the Origenboard stuff sort-of working on phones/tablets.

But that just puts us into the stone age...  The published code is crippled compared to what runs on any Samsung phone or tablet, even compared to the very first ICS hwcomposer releases.  There are massive architectural differences between the code and any functional binary in existence.

There are significant memory management changes from ICS to JB which are not covered in the source code at all.  Interestingly enough, despite this, ICS hwcomposer binaries work fine with JB Mali/EGL blobs.  So there isn't too much architectural change (other than gralloc/Mali) going from Blob ICS -> Blob JB.  However, what changes DO exist in those blobs are of major important - r2p4 Mali/EGL blobs result in SEVERE memory leaks when used in Jellybean.  r3p0 does not - but Samsung is using r2p4 nearly everywhere with undocumented framework hacks to work around the leak.

So no matter what, we are stuck with outdated and barely functional Mali/EGL, either the "deadend" r3p0 which can't be used with the reference source published, or "ancient" r2p4 from the reference repos that lacks all of the Jellybean optimizations in newer r2p4 implementations, and is incompatible with any r2p4 implementation that ships with a tablet or handset.

Really, the blocker is, and always has been, hwcomposer and the rest of the graphics subsystem.  What they've published is CLEARLY significantly different from what is in use on any device ever shipped to an end user.  Their reference code is so outdated that the usual trick of figuring out which commit a manufacturer branched from and diffing from there fails (see what +Daniel Hillenbrand did with the Xperia V and CAF reference source), which (when successful) allows you to start tracking the upstream reference source - the disconnect is too big, and the commit that Mobile started from simply doesn't exist.
Hoping that the next GoOgle Nexus is a Phablet... then it will most definately be BYe BYe Sammy
Add a comment...