[Nook HD, HD+ Android Development] amaces:
Hey, [MENTION=5664601]Jon Lee[/MENTION], I owe you an update about what I ended up doing, and about what we found about the composer history.

Lacking revision information, I started with manual file-by-file diffs, and realized that pvr-source differs only with respect to build configuration. I incorporated some of what I thought are optimizations in this commit. If you send some sort of email handle, I can attribute the Git changes properly, since they do improve things ;)

The HWC sources were pretty similar to CM11, as we established, so I did a partial revert (hwc & include only) to a state before switching to omap4-next; the other code (bltsville, domx, edid, etc) is pretty much unchanged. So, I changed the build configuration to overload only the composer and needed headers, planning to follow up on your other changes.

In the meantime, Hashcode started looking into this as well; he used the d-jb-mr1-release branch on OMAPZoom. It turns out that the CM12.1 composer sources are newer than in CM11 after all, but in ways that are detrimental to us while using API 1.0… CM11 stopped roughly here, while hardware/ti/omap4 acquired this, which seems to be the major culprit.

Looking at SurfaceFlinger logs (dumpsys SurfaceFlinger|grep -A 10 type), it looks like we avoided underflows by converting the fourth and fifth accelerated overlay to GLES (with four or fewer overlays, HWC does everything). The preparations for API 1.1 moved all five overlays into HWC, which the current PVR/DDK doesn't handle well. It would've been great if it did, since GLES is not optimal here, but thankfully this doesn't kick in very often (in my use, at least).

At any rate, Hashcode will fix this in the common repository, probably by reverting c3117a24cb2c97b467032adb6e204f575414c915, so my local hack will not be needed for long.

Yeah, a readahead of 256-512 KB is good, but it turns out that setting it globally is a bad idea; zRAM block devices need as little latency as possible. Maybe this newer zRAM driver ignores global readahed better, but I think it'll be sufficient to set it in init.rc only for physical mmcblk[01] devices. Not sure which value yet, probably depends whether we stick with ROW, or switch to FIOPS, or BFQ.

There are a couple of un-merged BT commits (see http://review.cyanogenmod.org/#/c/103111/), although for some problematic car-kits. Try the build in experimental, which has these included.

Based on http://review.cyanogenmod.org/#/c/102325/, it looks like they hide it now by default (too buggy, I guess). I can try to bring it back with an XML overlay in the next set of builds.

Told ya' :)

Very odd… If the issue is underflows, they'll show up in the logs. I suggest connecting to an adb shell, replicate the conditions that trigger the issue, then extract logs just after it happens (i.e., adb shell dmesg > dmesg, and adb logcat -d > logcat).

On a softer side, thanks! Although this has started as a self-interested project, I've been on the other side for years, and I know how frustrating it is when people disappear without warning, or worse, have the emotional intelligence of a baboon ;) Obviously, you have to desensitize a lot on XDA, which is hard… There were a couple of occasions when I wanted to snap, but then it'd be a lost cause already, so I'll do subtle snide instead ;)

I did consider keeping only the GitHub repos, and forcing people to bake their own ROMs (which some already do), but then I remembered how inconvenient it was to find a spare Linux box, and basically dedicate it to this work. My MBA would've certainly been dead by now, had I not had access to a real workstation.

Initially, the idea was to keep the information barebones, possibly scare off folks who would break their devices… That didn't work so well, but we're now close to a very usable state, which means that I will slowly rephrase the OP, make things easier to follow.