[Nook HD, HD+ Android Development] amaces:
LiveDisplay is Alive

Just a heads-up that CM's color calibration finally works on the latest builds. I've been pining for something like f.lux/CF.lumen, but hardware based (OpenGL or overlay solutions are too resource intensive on these devices); we finally have it, with minimal impact to performance.

Also, the latest CM builds are testing a different strategy for zRAM, and memory management. The latest kernels in experimental make these changes stable, and definitely more usable. Basically, I'm adapting empirical results in this study, which is pretty much the opposite of what Google recommends ;) The only thing that might suffer a little bit is gaming, although I'm sure people will report here if things need further tweaking.

Interesting that 60fps works on hummingbird, but not on ovation. Both are capable, so it must be some obscure configuration.

If you're using the default CM launcher (which is pretty buggy right now), I think rotation is not enabled by default. Recently, they also changed the way you'd enable it: http://review.cyanogenmod.org/#/c/126825. I'll try a configuration overlay to switch it on by default, although there are so many better launchers, including Google's.

It shouldn't deplete that fast, but yeah, it won't last for a week like in the old CM11 days. Try looking at deep sleep ratio and possible wakelocks, things that were intermittently discussed on the CM12 threads. Otherwise, yes, kernel might be a bit of a culprit (even Hashcode remarked about it).

P.S. I don't think Greenify (and Amplify, etc) is really needed on Marshmallow, and it might actually have the opposite effect by waking the device needlessly.

People claim many benefits with F2FS, including better battery life, and whatnot ;) It's certainly better for /data and /cache, even if you only care about wear leveling and a bit of extra write performance.

Haven't got those in a long time, but the solution discussed in the past was suspending/resuming the panel; no need for a full reboot.

I'm not sure that our WLAN drivers support that feature, and I'd personally turn it off if it were available.

You shouldn't wipe /bootdata… Also, eMMC is the whole internal storage, not a certain partition. Yes, TWRP mounts what you find in /sdcard at /emmc, but you shouldn't have to wipe that either. It's /system, /data, and /cache that may need that, although you may have gotten to a point where you need an external recovery to fix things.

In terms of SD card recovery, verygreen's should always be the first choice (at least, till we have external TWRP images).

Again, nothing is written in /bootdata during flashing; you probably mean /boot where the kernel lives, which is written as raw image. I've copied instructions from the CM12 thread to the OP here.

That leads me to believe that you chose adopted storage (the second option) when you let it “fix” your SD card, in which case external storage is only readable in Marshmallow now… They're working on supporting this feature in the next major version of TWRP (2.8.8.0). If you don't have anything important on that card, you should format it as portable storage.

Mine only does that when I reboot the wireless AP; maybe your signal is intermittently weak. The WPA supplicant seems to have issues with disconnects, and I haven't figured out why.

Just a fluke; there are three different ways to change the apparent thread title with this DevDB thing, and had inadvertently overwritten the date when updating the OP.

Oops, you're right; I haven't carefully checked what changed with that block of code. As I said, I wasn't planning to use this branch before fixing the other stuff. Good job finding and fixing it; backslash and indents added, and change pushed to repo.

The ROM sizes should be different though, not by much, but still a few MB.

Can't think of anything to test yet, and I'm also hoping that JustArchi, whose base commit I'm modifying, will redo all this laborious work for Marshmallow. Otherwise, there are many, many different flags that can be added on top of the base -Ox level, like I did (e.g., additional Graphite optimizations, loop unroll, alignment, -marm/thumb, etc, etc). Only some actually improve things, some are clearly detrimental, so it's very tedious to empirically test all combinations. It becomes more of an intuitive process, if you're inclined (and have time) to read about GCC's magic flags, then the ARM-, Cortex-A9, OMAP4470-specific stuff…

Same UBERTC 4.9 Android EABI prebuilts; was testing the experimental EABI 6.0 for kernel mostly because we can ;) Also, was curious if it's worse for battery life like EABI 5.2 was initially. I haven't made up my mind, but I also don't see an obvious improvement. The benefit with GCC[56] would be even more aggressive optimizations, which GCC 4.9.4 chokes on, although we can probably squeeze a lot more performance with a better kernel, and memory management.

I don't really flash more than one or two full ROMs per week; lots of kernels since often my changes are fully contained in the boot image, and any /system changes can be adb pushed. But yeah, if you have the disk space and computational resources, you might as well check that ovation builds properly, or you could be another purveyor of these builds ;)

Not sure what to say since I definitely didn't change the HW composer stuff that fixed the underflows last summer. Can you pull a dmesg when the glitches happens so I can check if underflows are indeed responsible? They used to happen reliably when typing in Chrome's address bar with Google or AOSP keyboard. Also, check some of the old remedies here.