Stock rom .

I did some heavy testing of the new CM12 base yesterday, and I agree with all the previous posters...
THX a lot to RealJohnGalt: It's a huge improvement!

pros+
- No Proximity/Orientation sensors problems anymore (note: I was using the 'unblank-restart-sensors' script before)
- Bluetooth audio: Perfect! (tested with a Bluetooth Headset and in my car)
- Bluetooth call: I got bad sound quality in my car, but it is basically working. The other person rated the call quality as 'good'.
- Camera recording was working once, but crashed when I tried to record a 2nd video.
- GPS is working great and is very accurate, but I miss A-GPS. (tested with MeeRun in my car)

cons-
- We still have that sensorsfwd/sensors.qcom bug in idle state.


I am still convinced that 'conservative' is the better CPU governor setting than default setting 'interactive'. I get better results in 'top' & 'powertop' for running programs and for idle state.
I created a little script that you can use as systemd.service or as simple 'toggler' from command line.

Installation as systemd-service:

I use nano...
1. Create a file '/etc/systemd/system/cpu-governor.service' with the following content:

2. Create a file '/usr/lib/systemd/scripts/cpu-governor' with the following content:

3. Enable cpu-governor.service (start on every boot)
After a reboot the CPU governor should be set to 'conservative'. You can 'start/stop/restart/disable' the service or check 'status' with systemctl.

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.

I was able to use a mixture of similarly tagged (from strings) blobs from onyx and hammerhead with edited configs, to get similar sensors process cpu usage to onyx. But with the functionality and responsiveness of pure hammerhead blobs -- so no laggy z axis or nonfunctional proximity .

The problem lied with configuration (though not sure exactly what yet), and we needed some different blobs to load some different options. The good news, is that memory usage is down for the processes. And cpu usage is far lowered (around what kimmoli witnessed on onyx).

These are still all 5.1 targeted blobs and configuration options, except for the hal. This is for the cm12.1 based sfos, and should be flashed on top in recovery.

https://www.mediafire.com/?2wtaz444yrl927q


Edit: I made a piratepad for the cm12.1 base to make fresh installs a bit easier until it gets to OBS. Check it out here: http://piratepad.net/bhP8fbzYgT

Don't flash the latest sensorsfix2.zip as it doesn't solve the issue: After locking and unlocking the device the sensor CPU processes stay at a very high level of about 7-9 %, at least this holds for my n5 model.

edit1: same seems to hold for sensorfix.zip after reflashing it, can someone confirm? did not checked the zip contents.

edit2: sensorsfix2.zip contains other shared libs and config files.

edit3: copied over ll's shared object file from http://talk.maemo.org/showpost.php?p...&postcount=526, looks much better now

How is the WiFi connection compared to the CM11 base?, in Sailfish for me it has been considerably weaker than Android.

Hi. I've been testing Bluetooth with this new release cm12 based and I can confirm (at least in my n5) two things:

-One good: connection now works way better. I mean, now I can connect and disconnect to my car audio and it stays working. Music sounds great!

-One bad: audio when making a call still has issues. An ugly noise over the voice as in cm11 based.

I'll keep testing. Great work guys!!!

Looks like we're actually back where we started with the sensor issues :/.

To put the second zip "fix" in perspective, I haven't been able to see above 1.3% cpu usage out of either sensor process -- no matter locking/unlocking or movement.

I don't get any change with the blob you linked, except for the z-axis now lagging. I updated the piratepad with a link and note toward the top. I'm not sure of a real world issue with having the z-axis lag, so if we're not able to come up with one, we can use llelectronic's blob.

Regarding audio quality issues on the cm12.1 base, please try running the following (over ssh or terminal):
If this works, it will be bundled in the next build and obs stuff with https://github.com/RealJohnGalt/droi...1d58f6decdda32

I do agree that sensorsfix2.zip did not change a lot, but in combination with the mentioned 'sensors.msm8974.so' file (see 'edit3'), I have much better stats and also the 'sensors-in-idle-bug' is gone.

I confirm that z-axis is lagging with the 'sensors.msm8974.so' file mentioned in 'edit3'.


I made the links and rebooted, but see no change in sound quality for Bluetooth phone calls.

I recorded a sample music/call file from the earpiece of my Bluetooth headset to show you the difference in sound quality between Bluetooth Sound/Call...
https://www.dropbox.com/s/c0o7d9t0ne...-call.ogg?dl=0

WiFi connection is a bit weaker than with Android but not that bad. In my apartment, the kitchen is a critical room when it comes to WiFi. I lose connection a little bit earlier with SailfishOS, but we are talking about 2-3 meters.