Advertisment

Search

Sunday, January 8, 2017

NEW BUILD! Beta 4 CyanogenMod 13 for Huawei/Honor HI6250 Variants

Most of you are probably already aware but since Beta 2, I've been experimenting with trying to support more of the Huawei/Honor Hi6250 variants such as the Honor 5c. A few people from the Honor 5c community had tried my ROM and had said that it worked except for the camera. I was already so familiar with the way the stock ROM worked that I was certain that fixing the camera would be easy and it was. From Beta 2 on to Beta 4 new models kept showing up and working and supporting these new models is fairly simple. All I have to do is set some properties in the system at the correct time to configure for a specific model. Since I don't own these other models I can't really test things but as long as it's as simple as setting these properties, then these models will be supported. Currently the list of supported models, which includes the Huawei P9 Lite | Huawei GT3, Honor 7 lite | Honor 5c | Huawei GR5 mini looks like this:



  • VNS-L21
  • VNS-L22
  • VNS-L23
  • VNS-L31
  • NEM-L21
  • NEM-L22
  • NEM-L51
  • NMO-L21
  • NMO-L31


Ah Bluetooth you pain in my ***. Bluetooth pairing has been an issue for quite awhile and I had almost given up on it. I couldn't seem to find any new ways to approach the problem. I knew that a command was "timing out" (optcode 0x40f) to be exact. I checked the logs from the two android phones and I could see that a connection was being established but, when this optcode was send, there was simply no response ever. In that case the bt hci_layer causes bluetooth to be reset. I tried to find some information about what optcode 0x40f did but I couldn't find anything. I tried serveral other small experiments to see what effect they would have; like increasing the length of the timeout, trying different build configs for the BT HAL. Nothing seemed to do anything. I gave up on it but I never forgot about it. Recently, enzo24754 @ XDA, re-mentioned that he had a work around that allowed him to pair to his device. He had mentioned it before but it was at a time when I had less information about the issues and so, in the confusion, i disregarded it but now, I thought that perhaps I could learn something new about the problem from this workaround and asked him to explain it. I could not get it to work. Perhaps it was just my scenario that didn't work but when another user at XDA said that they had gotten it to work and described in more detail the method that he used it got me thinking. The procedure that was described made me think that perhaps this "optcode" was being issued to early; that maybe it was being send before the connection was established and therefor it was never received and ipso facto, a response was never received and boom "timeout".

So with that in mind I decided to play around with the BT hal and see if I could delay sending the 0x40f optcode until the connection was established. After I got my code all set up and rebuilt the BT hal, it didn't work. The problem was still the same so I thought well, what if I just block the 0x40f optcode. After all you can't timeout on a request that you did not send right? RIGHT! Blocking the 0x40f optcode allowed normal pairing. I just hope that it's not needed....


I know that many of you are wondering about a custom nougat ROM and whether or not I will develop one. It was my intention to build CyanogenMod 14.1 but most of you know that CyanogenMod is  a dead project and the devs have created a fork to continue the work called LineageOS. I have already tried to get through a build of LineageOS 14.1 a few times and I just couldn't get throught it; build errors. I pretty sure they were not related to my code but could have had something to do with my build environment or could have just been a few poorly timed repo syncs ( I did try a few times ). So, I think I'm just going to wait awhile and then sync a couple of nougat ROMs
and if one fails I'll just try the other... might be awhile though, I'm trying to get the money together to get a faster, more powerful laptop so I can do builds more quickly...

Thursday, December 8, 2016

NEW BUILD: BETA 1 - CyanogenMod 13 for the Huawei P9 Lite.

Well, it's been a long time in comming. The trees have finally made it to a point where I can call it "Beta". All of the hardware is on line with just a couple of minor exceptions namely, the fm radio and the "pseudo/emulated sensors".

I do not believe that we can use stocks implementation of the FM Radio and we may not be able to use CyanogenMod/AOSP implementation either. The latter is aimed at qcom which does not work for us.

There is also a bluetooth pairing issue which I have not been able to resolve yet. All camera apps should work properly now and NFC is online



This ROM will remain in beta until:
  1. The bluetooth issue has been resolved.
  2. Sepolicy has been fully implemented.

Big thanks to Daniel Múčka (dady000 @ XDA) for his work on NFC, for correcting a lot of my typos/derps and other contributions.


Download on the download page as always.

Thursday, November 24, 2016

NEW BUILD! Beanstalk 6 for the Huawei P9 Lite

So, here it is, Beanstalk 6 for the Huawei P9 lite. This ROM has all the extras that any ROM ever had and then some. I think your going to like it.













NOTE: Fingerprint enrollment does not seem to work BUT if you dirty flash this over CM13, your already enrolled fingerprints will work! 

Install like this:
  1. Install cm13 and enroll your fingerprints (if you have not already).
  2. Uninstall any themes and go back to stock theme ( if you already had cm13 installed ).
  3. Flash Beanstalk 6 (Don't wipe anything... just flash and reboot).
  4. Reinstall your themes
  5. Profit
Happy Thanksgiving!


Download: here

Please do not mirror or re-post my files! Link to this page!

Thursday, November 17, 2016

NEW BUILD! CyanogenMod 13 for the Huawei P9 Lite

From day 1 we have been operating without a hwcomposer. We have also been experiencing a lot of minor graphical type issues and everyone ( and I mean everyone ) assumed that it was because of the missing hwcomposer. Well, I learned long ago that just because "A" precedes "B" doesn't mean that "A" causes "B". I knew that the hwcomposer was insignificant because codinalte runs just fine without one and I did a little experiment. I deleted the hwcomposer on stock and rebooted. Guess what? It ran just fine! There was absolutely no change in the way Stock operated visually that I could detect. So the question remained, "What is causing these minor graphical issues?"


So, finally, since everyone assumed it was the hwcomposer, I thought I'd write one. I personally thought there might be a problem with vertical synchronization and the hwcomposer (can) be responsible for that, but during my debugging, I noticed that the default number of surface buffers in surfaceflinger was 2. In the back of my mind I already knew this and 2 buffers has always been enough for my previous devices but something made me decide to experiment with it. So, I bumped it up to 6. Then I tested. I must say that the graphical glitching was plaguing me. I tried so many different things to try to get it fixed and every time, I thought, "It's fixed!"; Boom it would happen again. So, I kept expecting it to happen again but it never did! All it took was bumping the surface buffers to 6. Not really hwcomposer related at all. I'm so glad I took my time and followed my instincts.

Since that was fixed I buttoned up the hwcomposer that I wrote and it works just fine. I'm uncertain about the vsync implementation. When enabled, surfaceflinger quickly decides that it's not needed and turns it off and indeed, it may not be needed because visually, everthing looks awesome.

This build also has a new opensource power HAL that I wrote. I must say that I'm quite happy with the results but it's effectiveness will depend on usage. Please let me know about your "battery life" experiences. Is it better/worse than before? Is it better/worse than stock?

Battery modes now available in Settings.


Wifi/BT off, 2g no data, balanced power profile, no gapps

Wifi/BT off, 2g no data, balanced power profile, no gapps


I also had a chance to test A2DP and for me it's working perfectly.


I also fixed Screencast and no, the issue is not related to hwcomposer. It was a media codecs issue. Our hw stagefright codecs do not play nice with standard color formats. So, I just modified the "/etc/media_codecs.xml to prefer google codecs over our hw codecs.

Download and more details on the download page as always.

Thursday, November 10, 2016

NEW BUILD! CyanogenMod 13 for the Huawei P9 Lite...

Camera and GPS are the big two that are left. There are also some smaller issues and some might say, "Hey what about the gyroscope." Well, further research has revealed that there is no "hardware" gyroscope. Huawei has some sort of emulated gyroscope on stock. As I have been saying for awhile now, it is my intention to create a standard sensors library and perhaps at that time, I can figure out how to "emulate" gyroscope data using data from the existing sensors but for now, it goes to the back burner. NFC also needs attention but not a high priority.


In this build, I've implemented some, rather hacky, fixes to prop up the Camera. Personally, I don't like these hacks but for now, they make the camera much more use-able. The issues with the camera are 2 fold. Fold 1, perfhub. Perfhub is a daemon that the Camera daemon "HwCamCfgSvr" communicates with for "copybit" operations. Both of these daemons are proprietary blobs and getting in the middle of them to correct issues is difficult. Perfhub often crashes when attempting to close copybit. Closing copybit happens when switching between the back and front camera, closing the camera, after photosnaps; at the end of almost all camera operations. First I tried to reverse shim the function that crashes. The result was pretty good. The camera was stable. Photo-snap worked on both cameras but video recording did not. So, it was an improvement and it was clean ( no crashing ) but, no video recording. So, then I thought well, if perfhub is going to crash, init is going to automatically restart it because its a non-oneshot service. So why doesn't the camera work after perfhub restarts? Well, it seems that communication between perhub, media, and HwCamCfgSvr is broken and does not reinitialize if just perfhub is restarted. Solution: restart them all if perfhub restarts. It's not the best solution but it sorta works. Hopefully, I'll come up with something better soon. Fold 2: copybit operations parameters seem to be off at high resolutions. Miraculously, copybit does not fail at high resolutions, but it creates an image that is the wrong resolution and a much lower resolution. I'm not quite sure why this happens.



I've also added a bunch of minor fixes and features. Check the download page for a complete list.

Download available on the download page as always...

Thursday, November 3, 2016

NEW BUILD! CyanogenMod 13 for Hauwei P9 Lite

Since I got my laptop back up and running, I started looking at offline charging. It's something that should be fairly easy because I've worked on it for several other devices. Booting into charging mode mode is not really that different from booting normally. Init just chooses to initialize somethings and not others when in this mode. The problem with charging mode was that it did not show anything on the screen and it eventually rebooted to recovery. So, just like with the initial bring up, my first task was to get adb working but with so many init scripts it was difficult to tell just what things got initialized on "charging" mode vs "normal" mode. I decided to implement an "lpm.rc" to simply diagnostics.

After that was done and I got adb working, I was left with a "charging" mode that was just a blank screen but at least there were no "reboots to recovery". It just sat there happy and blank. After some poking around I noticed that the framebuffer did not have a "mode" set so I wrote the only mode available to /sys/devices/virtual/graphics/fb0/mode and BAM! the charging screen came on!



Then I turned my attention to fingerprint sensor. My first idea was to push the fingerprintd from CM on to stock and see if it would still work. It did, so I added a bunch of diagnostic code to CM's fingerprintd and pushed it on stock and watched the logs. Then I pushed put it on CM and too and watched the logs... Nothing. After thinking about if for a while I realized that fingerprint is a "security" device and there were parts of security that were still broken; the hw keymaster! I remembered thinking that the hw keymaster might not be so hard to fix and it wasn't. It turns out that it just does not support RSA for encryption and decryption and after removing attempts to add RSA for those "2" purposes, the keymaster was online and working; and so was fingerprint!






So, in this build:

  1. Offline Charging fixed.
  2. Fingerprint fixed.
  3. Sdcard detection fixed.
  4. Experimental graphics property tweaks.

INSTALLATION INSTRUCTIONS HAVE CHANGE!

Download available in the downloads section as always...

Tuesday, November 1, 2016

TWRP 3.0.2-0 for Huawei P9 Lite

Why build another TWRP when we do have one that works? Well, my cm builds do not currently support encryption and stock forces encryption on us with a key that no one knows. This makes the installation of CM a bit complicated and once CM is flashed the TWRP that we are using can not mount /data any more. So, got this idea for a TWRP that could switch everything based on what ROM was installed. I've been working on it for a while now and it ready to be released.


On Stock
On CyanogenMod


This TWRP has a few advantages over the one that we are currently using:

  1. The brightness slider works
  2. Battery percentage is reported at top right.
  3. English is the default languages with support for many more.
  4. TWRP settings are stored in /cust so they are preserved across /data wipes.
  5. Compatible with my Cyanogenmod 13 builds.
  6. USB Host mode switches.
Download available in the download section.

P.S. If it wasn't obvious with this post, I have gotten my laptop repaired and it seems to be running very well.