[ROM] [7.1.1] [NOUGAT] CyanogenMod 14.1 for Nexus 5 [CAF]

Karan_Brar said:

Haven't tested thoroughly but first impressions are that previously experienced scrolling stutters on google+ are gone and Youtube video rotation and changing from fullscreen to regular is pretty smooth now. Thanks!

Click to expand...

Click to collapse

This time I'm actually a bit proud of myself because the display abstraction layer is a beast. It took me about 8hs to nail it, here is how it went and it would be handled comparably at QCOM:

There is that bug report and the bug is easily reproducible, which is good. You try to find out where it all starts, there is the kernel, HAL and framework (surfaceflinger). I initially suspected a framework bug because our chipset got dropped by QCOM and I saw they even reverted workarounds for hardware-bugs because hammerhead is now abandoned. That kind of lead to nothing. I also saw they cured a suspected framework-bug by a fix in the kernel where several mutex locks were in a bad order but that was not our bug. On the positive side, we have all these fixes on board as well now.

So the HAL remains and I went through commit histories of 5 different branches, AOSP hammerhead, shamu and newer devices plus two current CAF branches. You can see where the old ass HH branch was left during stone-age. In newer HALs like hhcaf's they introduced some intelligence to layer handling and this is where our first-generation Snapdragon 800 fails. Interestingly it took QCOM 4 attempts to finally make their routines work.

I started to analyse frame by frame and something was weird, hidden layers appeared visible. So I looked at frame by frame and layer by layer. Having our music player's track list for reliable testing was invaluable here, thanks for the hint whoever posted it here. I noticed that there are cached dropped layers that are not in the backgroud, very ugly, this is what's causing the visual lags. So I used the observed pattern to create a filter for the last but one layer that is supposed to be hidden.

Because this error is very visible to the user, the QCOM engineer would open a ticket for the hardware team and have them check if it was a hw bug or limitation. In our case the answer would probably be it's a limitation of our hw revision. This would be good news for the engineer because his work was finished now. In this case a workaround like ours is fine; in the other case (and on showcase chipsets) he had to dig deeper and had to investigate why the layer was handled like it is.

The rest was cleaning up and optimizations to minimize the scope and footprint of this patch. Basically we're rendering that single bad layer on the GPU while the rest of the layer in handled by HWC in the framebuffer cache.

Please, no drama, it's all good.

I cannot spend any more time trying to fix this. There is a bug in the chipset where the attempt to change the state of a clock happens during the retention phase on the target cpu. Krait does not like this and dies. First I removed the spinlock that deadlocks, then I ported an old fix by a QCOM engineer for us (Matt Wagantall and his wife were or or still are with Cyanogen, btw). I'm pretty sure this bug was fixed with the 801 version, our old Snapdragon 800 has a different kernel-space clock-handling. I have neither the skills or equipment to fix this, especially because I never had any issues with my device(s) for over 3 ys. now.

On friday I started from zero with the latest available msm8974 branch, added our boad and device tree files plus all drivers. It felt like ****, it crashed in various places, it was a mess. Our ancient version is a *****, when I was playing with the Oneplus One that has the 801 revision, it was a walk in the park: pull CAF, enable all the fancy tweaks, rock stable. On hh I had to fight with everything.

My learning is: it's not worth it. Given how long it took for LGE/Google to fix the N5 when it was new (daily kernel panics and everything) or Motorola with all of their amazing people working on the N6, I have to pull the plug now. I know what I'm capable of and I know what I will never be able to do. Just yesterday I learned how the facebook app kills our batteries and how QCOM messed up certain settings for the interactive governor but it's too late now.

I am already late with my training for the coming bike racing season, I need to catch up quickly if I want to top my last season with 4 wins (my goal is 10 wins in 2017 ). Catch ya all later and I guess I'll at least keep sources up to date.

quimbexa said:

Are these fixes going to be included in the oficial nightlies?

Click to expand...

Click to collapse

The kernel and framework side is already there, I'll merge the HAL fix later today (I just cleaned it up earlier before the morning run to work ).

I'm pretty sure I fixed HWC for us, butter is back and battery will be even better.

Please throw some games, videos, youtube and general stuff at it. Look for anomalies and catastrophic failure.

I thought, it's time to catch up since nightlies will start tonight. And if you believe it or not, hammerheadcaf N is smoother than the ****ing brand new Oneplus 3 with N that I own as well. In fact it's so smooth that it hurts!

Please note: This is the very first build, I quickly threw together the SELinux policy updates so that cam works etc. Since we use camera HAL2 we do not even need the wonky framework hax. Google and CAF rock

Have fun. I will push the sources to my git as always.

cm-14.1-20161108-UNOFFICIAL-hammerheadcaf.zip


Edit: HDR+, photoshere and all that works with Google's cam.