The Saga of a CyanogenMod Exynos4 device maintainer - I9300 Jellybean, and things come to a headDisclaimer: 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 https://plus.google.com/u/0/101093310520661581786/posts/SUZYDEFj8CsJust a warning - I've been sick for a few days which is why this update has taken so long, and in addition, this period was VERY hectic - So things might be a bit disorganized here.Integrating I9300 Jellybean
This was easier said than done. To give a bit of history, ARM versions the code drops of their Mali driver to vendors, which vendors then integrate. Some vendors really hack things up severely (look at all the frequency control cruft in the Mali platform code for pegasus, aka Exynos 4412).
ICS used Mali r2p3 drivers. The initial I9305 leak and I9305 kernel source used Mali r3p0 drivers. However, by the time I9300 Jellybean went live, they had reverted to Mali r2p4 drivers. The Mali r2p4 drivers in the official release, when various framework workarounds are put in place, seem to perform better than the r3p0 drivers that Samsung seems to have dead-ended us with.
The problem is - Mali drivers older than r3p0 need SOME sort of workaround in the frameworks in order to not leak memory like a sieve when used in Jellybean. Samsung refuses to document this workaround for their broken r2p4 grallocs. So we were able to finally get rid of the Jellybean gralloc memleaks, but at the cost of being stuck with dead-end blobs that are unsustainable in the long term as Samsung has stopped using them and gone back to r2p4.
The good news is that gralloc, EGL, and the Mali libs work with either Exynos 4210 or 4412. As a result, the I9300 release was able to fix the memleak on I9100/I777/N7000. However, we were not able to use the I9300 hwcomposer blobs - there are slight differences between these, including dependence on libfimg3x vs libfimg4x, among other things.
Edit: I forgot to mention this in the initial post, but this was the third cycle of attempts to get source-based HWC working with our devices, as without it, 4210 devices were stuck using legacy ICS HWC. (Sorta works, but no vsync support and no way to add it to a blob.) I think I spent 10-20 hours/week in my evenings/weekends fighting this with absolutely zero progress...
Edit 2 (I warned you guys about this...): One issue I think I mentioned in the past is that Samsung's kernels tend to have majorly mangled bcmdhd - Things were worse in the I9300 JB drop - Tethering totally failed with the new bcmdhd driver under all circumstances. No one has yet to figure out why, and since Samsung only does tarball drops with no commit history, it's hard as hell to figure out WHICH thing changed. It's probably something that would have been fixed if it were one of the only issues, but the problem is, there are so many issues piled on top of each other with these devices that things which might be an attackable problem if they were one of a handful become massive issues when combined with 3247927430423 other things that are broken - When you have that many issues, there just seems to be no end in sight, and far less motivation to keep beating on them.Hillenbrand (codeworkx) hits his limits
Around this time, the longest-active Exynos4 CM maintainer, +Daniel Hillenbrand
(aka codeworkx) hit his limits - http://codeworkx.de/wordpress/2012/09/23/having-a-look-at-my-magical-orb/
- I think he's lasted longer than any other Exynos4 maintainer has, from start to "I've had enough of this crap" - Typical longevity of other maintainers has been on the order of a year or less, see +Atin M
as an example.
The reasoning for this was - Exynos4 is a nightmare platform to work with, the only worse platform being Tegra (and we all know about how they are with regards to open source, being the recipient of the middle finger and a big "FUCK YOU" from Linus Torvalds). Qualcomm has robust and up-to-date reference sources at CodeAurora that actually WORKS with little effort on handsets (HTC requires significant work, Samsung requires some, Sony handsets require almost no work to get CAF code working as Sony is smart and doesn't deviate from the ref source unless they absolutely HAVE to.)
As an example of how up to date CAF tends to be - See https://www.codeaurora.org/gitweb/quic/la/?p=platform/hardware/qcom/display.git;a=blob;f=libhwcomposer/hwc.cpp;h=a2ea3c9a1f98190aae0b7cbdc340d2003d9bf7af;hb=2db42eda10d88d0547bddf419d8eca47f0a8cfbf
- Android 4.2 has only been out in AOSP for a week, and CAF already has 4.2-related sources. Now this is partly due to the Nexus 4 - however also note that CAF has a SINGLE UNIFIED HWC for all recent SoCs - Samsung changes the whole infrastructure with each generation, so Exynos5 stuff (Nexus 10) is of little to no use on Exynos4.
Edit: One thing about CAF: Qualcomm does give undocumented "blobs" to their customers. These consist of "optimized" replacements for parts of the Android system. HOWEVER, the penalty for not having these blobs is reduced benchmark performance (which is why, as I understand it, the Optimus G outperforms the Nexus 4 in benchmarks), NOT complete loss of some aspects of functionality as is the case with Samsung's nonfunctional reference source.
TI's OmapZoom is similarly up to date and robust. The end result is: http://codeworkx.de/wordpress/2012/07/24/jellybeanz/
The closest we had were the Insignal reference sources, and Hardkernel's 2GB tarball drops. Both of these totally lacked commit history and were vastly out of date - ICS source code months after Jellybean was released. They also simply didn't work - with the exception of the OMX libraries (hwaccel video) and the FIMG libraries themselves, nearly everything else was broken. Using source-based gralloc would completely fail to function at all (black screen), libcamera was unable to capture even after multiple attempts to modify it to work with M5MO (Indicative of an underlying flaw in the core source code, as it did not take significant effort to get Exynos3 libcamera to work with M5MO on the Infuse, so it's not a sensor issue.), and hwcomposer was 100% pure placebo - Under any circumstances, its behavior was indistinguishable from having no HWC library present at all.
So between that, other things (see earlier installments of this saga for many examples), and Superbrick, pretty much all of the Exynos4 maintainers were at the limits of exhaustion with Samsung and especially with Exynos4.
I indicated that the Note 10.1 was going to be my last device, and I was not sure how long I'd be staying with the I777 and N7000, as I was exhausted at this point too. I was tired of being months behind the rest of the Cyanogenmod team because I worked with devices that had more blobs and more interface breaks in the blobs than any other device (Except for Tegra3 devices, but people already knew to avoid these unless they were in a Nexus.)
Sometime around this I emailed my contact with a request for hwcomposer source - no response. This was not the first time anyone had requested source, but I included pointers to the Omapzoom and CAF reference source as examples of what other companies were doing. (It makes the request more reasonable if you're asking for source of something that other manufacturers provide source for.) As to the lack of a response - My guess is Samsung's firewall ate it. God forbid you even mention the NAME of another company in an email to/from Samsung - the firewall will drop it. This makes proper discussion of why we're frustrated difficult when any meaningful email will get blackholed.
Not long after, a bunch of users on XDA unhappy with the situation started a social media shitstorm.Samsung asks for help
Our contact reached out to us to try and calm the storm. Mind you, this isn't the first time Samsung has had a social media storm/flood, and this isn't the first time we've been asked to try and calm it down. In the past, the storm contained unreasonable requests, like "Give us ICS for the Galaxy SL - we know you have it!" (Even though they didn't have a shred of evidence to support that claim) - We would help try to calm these down.
However, this time, Samsung had driven the community and a bunch of developers past the breaking point. +Daniel Hillenbrand +Guillaume Lesniak
, myself, and others (such as +Gökhan Moral
) were at the point where if Samsung didn't make significant changes, we were going elsewhere (+Atin M
had already retired long ago...). Thanks to Sony's great efforts over the past year AND Nexus devices being far easier to obtain, we did have places to go.
My response: "Give us what I asked for in my email last week to which you did not respond"
Daniel's response included numerous CAF links as examples of what Qualcomm was providing that Samsung wasn't
Atin echoed our feelings - We wanted reference source comparable in quality to CAF and omapzoom, not the broken crap that is out there now.
My role in this calmed down for a while, as I began packing for the Big Android BBQ.
My next post will be outside of the timeline of this saga - Rather than be the next installment in the history of this whole mess, it will be a technical summary of where we are. It will contain some minor spoilers, although I don't expect any of it to be surprising to anyone who has followed things thus far. The next installment in the saga will be coverage of the BABBQ.
Next installment up at: https://plus.google.com/u/0/101093310520661581786/posts/V8B4R5NTLqZ