[Nook HD, HD+ Android Development] amaces:
Oreo Manifest for Testing

That's only in theory… These things are not decided by the people who worked on the UM code, but rather by lawyers. Even when the legal issues are relaxed, you still depend on the good will of the people who are actually licensed to see the blob code. It's pretty messy if one party cannot see the sources, while the other doesn't have the hardware, but they have to produce some sort of blobs that work, allow for video playback, etc. There is very little 544/112 hardware out there, so it's not like we can just grab blobs from other devices. When you have to fix issues iteratively, and I mean tricky issues, where only your benefactor can possibly help, there's very little leverage on the whole situation.

They were never released properly, but rather leaked, probably via similar industry connections. Also, on DDK 1.8/9, you had a couple of Amazon KFires with similar 4470 hardware, so plausible deniability was different.

While I agree with you, and I've been frustrated for more than two years that I've been chasing these blobs, control over how the IP and hardware are used is pretty important to them. The chips themselves are not that obsolete; subsequent 544 iterations on OMAP5 and the like, still reuse much of legacy IP, albeit with more cores, higher clocks, etc. The UM code in the DDK supports legacy 540/544 on OMAP4 through whatever their newest chips are. They even removed ancient DDK 1.8 sources from the web, so lots of pissed off people if current ones are leaked. Best case scenario, we'd never ever touch other updated blobs, and the current ones still have rough edges.

Those are only prebuilts, no UM source core, and sadly those blobs are made for pretty different hardware (newer 544 variants that are dual-core). Even if they worked, TI builds theirs with much newer kernels in mind, and the DDK has several backends to talk to hardware, allocate memory, setup acceleration, etc. All these have to be chosen at compile time, as you can see from all the KM-side work that we did (https://gerrit.unlegacy-android.org/#/q/topic:omap-ddk-1.14+(status:open+OR+status:merged)).

These ROMs are developed with exactly that purpose in mind: a lightweight media-consumption device that's not frustrating to use. Unfortunately, we're always dealing with something frustrating given the many new drivers, kernel, etc. Everything was kept Permissive for a long time, since fixing sepolicy properly has always been lower priority work that I can never get to.

Have you tested the AOSP Oreo ones? They have the new Wi-Fi drivers, a tweaked P2P setup, and should have better support in theory.

Does that still happen only on the Lineage builds?

Believe me, people tried for years, but it's a subtle bug in the legacy 3.0 kernel, specifically something about I2C and regulator control. The new K3.4 should work better, but it's only used in the Oreo builds for now.

Yes, although I have to make room for it given all the N, O, and P manifests checked out already.

These should be userdebug builds; don't recall making eng builds in recent memory.

Interesting, I thought that part was still broken on the 3.4 kernel.

That was a pretty subtle bug that I missed, and was completely unrelated to write permissions. Fixed in https://gerrit.unlegacy-android.org/10523.

Yeah, these are the new Wi-Fi drivers that we're forced to use with Oreo. I need to fix these issues in kernel.

You can attempt syncing the Oreo manifest again. About pre-Nougat manifests, I'm afraid those will remain unmaintained for the time being.

Odd, I thought it still powered off on the new kernel with ext4.

Try the latest builds.

Yes, I've encountered this issue with F2FS on the new kernel. I believe it's due to the interaction between certain eMMC chips on ovation, with K3.4 and the more recent F2FS backports there. It's another insidious bug, and in my case, I can't even be sure that I didn't break my eMMC with the hundreds of experimental or incomplete kernel I've used on it. I plan to work on K3.10 at some point, which seemed to have some MMC layer fixes.

Indeed, we really need to start looking into seriously increasing system size, something between 1-2 GB. Pie is almost not buildable for this reason. I've been hesitant so far since I'd like to also create a vendor partition while increasing system, and REPIT might not handle new partitions. It's possible to do these operation with a custom script, assuming we're lucky, and our partition layout allows these modifications without disturbing more than cache and data. I haven't investigated these yet, but feel free to change these sizes as you see fit in the meantime.

Those artifacts are part of the rough edges that remain with the new DDK, unfortunately. Nobody knows yet if it's solely a 544/112 hardware issue, or a DDK-wide bug with certain EGL ops/HWC layers.

I plan to bring the new DDK blobs and kernel drivers to N builds as well. That should fix the GFX underflows on Lineage.