Regarding sensors, I've done quite a bit of testing recently. Also a small note: All sensor blobs (except sensors.msm8974.so hal) are LM48B in these builds. In these most recent tests, I got in the habit of replacing all sensor blobs and sensor-related configs.

Here's what I've come up with:
- Hammerhead LM48B sensor blobs segfault sensorsfwd. If I replace just the hal, we get a different result (like with the flashable zip), where cpu usage doesn't spike or go above 3~5%.
- Tested onyx 5.1 sensor blobs/configs from around LM48B, cpu usage was around 3~5%, could never get it to spike up like on cm11.0 base. Additionally the Z axis lagged, and no proximity.
- Tested all our sister variant (lg og) sensor blobs/configs from around LM48B. Similar results to onyx, except proximity works as well. Some of the variant blobs would start by reporting incorrect orientation as well (with extreme delay), which would require service restarts. Remember that firmware also varies per-device, so we may have been running into an issue there.

Ultimately I wasn't able to get above 5% cpu on the sensors processes like in cm11.0 base, or get much better functionality/usage than just using the cm11.0 hal with LM48B blobs/configs (like with flashable zip).

There was a qcom source leak from around LM48B from the cm team (while working with Oppo) that I'm going to look for again. It can perhaps help us get a matched set of blobs (targeted for hammerhead) working with sensorfwd .

Edit: also, I got partial functionality from selinux enforcement (new policies) . And a silly bug that kept spawning camera apps, so I ended up with ~20 camera app cards.

Edit2: According to kimmoli, he gets 0.6~1.0% with screen on with onyx. So that's something to aim for.