Hello dear Gernot Pansy by notz76, there is a lack of the latest build of Lineage OS 13 For Obake with LED indication of notifications, please collect it for us!)) Thanks!
[ROM][UNOFFICIAL] Lineage OS 13 For Obake [22/2/17]
- Thread starter notz76
- Start date
The problem with this latest build is that there's no su included.
Edit #2:
So.. This was a serious pain to figure out.
I followed these steps to get a working and root enabled "lineage-13.0-20170221-UNOFFICIAL-obake" ROM:
These hidden instructions are incorrect.
These are the correct instructions:
1. Download the fixed boot.img file attached to this post.
2. Replace the "boot.img" file in "lineage-13.0-20170221-UNOFFICIAL-obake.zip" with the one attached.
3. Download "addonsu-arm-signed.zip" for CM13 from https://download.lineageos.org/extras
4. Boot into TWRP 2.8.4 recovery.
5. Advanced wipe all partitions except "USB-OTG".
6. Mount USB-OTG (or adb push your files, I used a USB stick).
7. Install your modified "lineage-13.0-20170221-UNOFFICIAL-obake.zip"
8. Install your preferred Google Apps from opengapps.org.
9. Install "addonsu-arm-signed.zip" that you download from "download.lineageos.org/extras" here for Version 13.0.
10. Reboot
TL;DR:
The problem is that with this ROM, is that root was not part of the build.
So even after installing Lineage OS's "su" binary, a root process has to start it in daemon mode.
To do that, you need to install the su add-on, but the kick-off is controlled by the "init.cm.rc" script in the boot image.
I took the files required from the Lineage OS Moto X (Ghost) nightly, and repacked the obake boot.img with the updated versions.
Edit #2:
So.. This was a serious pain to figure out.
I followed these steps to get a working and root enabled "lineage-13.0-20170221-UNOFFICIAL-obake" ROM:
These hidden instructions are incorrect.
These are the correct instructions:
1. Download the fixed boot.img file attached to this post.
2. Replace the "boot.img" file in "lineage-13.0-20170221-UNOFFICIAL-obake.zip" with the one attached.
3. Download "addonsu-arm-signed.zip" for CM13 from https://download.lineageos.org/extras
4. Boot into TWRP 2.8.4 recovery.
5. Advanced wipe all partitions except "USB-OTG".
6. Mount USB-OTG (or adb push your files, I used a USB stick).
7. Install your modified "lineage-13.0-20170221-UNOFFICIAL-obake.zip"
8. Install your preferred Google Apps from opengapps.org.
9. Install "addonsu-arm-signed.zip" that you download from "download.lineageos.org/extras" here for Version 13.0.
10. Reboot
TL;DR:
The problem is that with this ROM, is that root was not part of the build.
So even after installing Lineage OS's "su" binary, a root process has to start it in daemon mode.
To do that, you need to install the su add-on, but the kick-off is controlled by the "init.cm.rc" script in the boot image.
I took the files required from the Lineage OS Moto X (Ghost) nightly, and repacked the obake boot.img with the updated versions.
Last edited:
So there's another problem with this image.
I noticed in the logcat that there was a constantly repeating message telling me that thermald couldn't find it's config file at "/dev/thermald.conf".
So more hunting through the boot image tells me that "/init.target.rc" is trying to call the "init.obake.sh" script.
That script is supposed to determine which variant of the obake platform it's running on (Ultra, Maxx, Mini), then symlinking the appropriate "/system/etc/thermald-[device].conf" file to "/dev/thermald.conf".
The problem here is that it's being called as an init "exec" command, which apparently was in the Android init specs, but never actually implemented in the code. So the file never gets linked, so there's no thermal control. Tracking down the change on google shows that it's probably been doing this across multiple obake ROMs for quite some time, but I can't be certain of that, since I only recently loaded a non-stock image.
In the end, I added the fix-up for both the SU daemon in "init.cm.rc" and a thermald service fix in "init.target.rc", then repacked the boot.img file.
This time, I just decided to pack the boot file into a TWRP flashable zip, so you don't have to reload the entire ROM.
So a fix for both issues consists of:
1. Download the "CM13obakeFix.zip" file attached to this post.
2. Download "addonsu-arm-signed.zip" for CM13 from https://download.lineageos.org/extras
3. Install the normal "lineage-13.0-20170221-UNOFFICIAL-obake.zip"
4. Install your preferred Google Apps from opengapps.org.
5. Install "addonsu-arm-signed.zip" from lineageos.org.
6. Install "CM13obakeFix.zip" from this post.
7. Reboot
If you already have this ROM installed, you can skip steps 3 and 4.
As an aside:
I installed this ROM because I had failed blocks in my "/data" partition (/dev/block/mmcblk0p40) that prevented it from being mounted.
The immediate result was that my phone would display the boot logo (in my case the "bootloader unlocked" warning), then go black and do nothing.
I was still able to get to fastboot and recovery, though, so I copied "dd_rescue" to TWRP and used it to clone off what I could to a USB stick. That's when I found that only ~6MB of the 11GB partition was bad, but some of those bad blocks were in the primary superblock, which is what prevented the partition from being mounted or fsck'ed.
Once I got my image, I figured I'd try to rebuild the partition and discovered that I could use the "-o" option in mkfs.f2fs to overprovision the partition in case of future failed blocks.
So keep that in mind if you start having data failures. You can just reformat and overprovision:
mkfs.f2fs -o {N} /dev/block/mmcblk0p40
Where {N} is a percentage of the space that will appear to be "used" but is actually reserved by the filesystem for data relocation as the underlying flash memory starts failing.
I haven't seen this posted elsewhere, so I thought it might help out someone else given how old our devices are these days.
I noticed in the logcat that there was a constantly repeating message telling me that thermald couldn't find it's config file at "/dev/thermald.conf".
So more hunting through the boot image tells me that "/init.target.rc" is trying to call the "init.obake.sh" script.
That script is supposed to determine which variant of the obake platform it's running on (Ultra, Maxx, Mini), then symlinking the appropriate "/system/etc/thermald-[device].conf" file to "/dev/thermald.conf".
The problem here is that it's being called as an init "exec" command, which apparently was in the Android init specs, but never actually implemented in the code. So the file never gets linked, so there's no thermal control. Tracking down the change on google shows that it's probably been doing this across multiple obake ROMs for quite some time, but I can't be certain of that, since I only recently loaded a non-stock image.
In the end, I added the fix-up for both the SU daemon in "init.cm.rc" and a thermald service fix in "init.target.rc", then repacked the boot.img file.
This time, I just decided to pack the boot file into a TWRP flashable zip, so you don't have to reload the entire ROM.
So a fix for both issues consists of:
1. Download the "CM13obakeFix.zip" file attached to this post.
2. Download "addonsu-arm-signed.zip" for CM13 from https://download.lineageos.org/extras
3. Install the normal "lineage-13.0-20170221-UNOFFICIAL-obake.zip"
4. Install your preferred Google Apps from opengapps.org.
5. Install "addonsu-arm-signed.zip" from lineageos.org.
6. Install "CM13obakeFix.zip" from this post.
7. Reboot
If you already have this ROM installed, you can skip steps 3 and 4.
As an aside:
I installed this ROM because I had failed blocks in my "/data" partition (/dev/block/mmcblk0p40) that prevented it from being mounted.
The immediate result was that my phone would display the boot logo (in my case the "bootloader unlocked" warning), then go black and do nothing.
I was still able to get to fastboot and recovery, though, so I copied "dd_rescue" to TWRP and used it to clone off what I could to a USB stick. That's when I found that only ~6MB of the 11GB partition was bad, but some of those bad blocks were in the primary superblock, which is what prevented the partition from being mounted or fsck'ed.
Once I got my image, I figured I'd try to rebuild the partition and discovered that I could use the "-o" option in mkfs.f2fs to overprovision the partition in case of future failed blocks.
So keep that in mind if you start having data failures. You can just reformat and overprovision:
mkfs.f2fs -o {N} /dev/block/mmcblk0p40
Where {N} is a percentage of the space that will appear to be "used" but is actually reserved by the filesystem for data relocation as the underlying flash memory starts failing.
I haven't seen this posted elsewhere, so I thought it might help out someone else given how old our devices are these days.
Next up - Notification lights,
The problem with notifications is the library used to control the LEDs.
There's no good source code that I could find that allows for proper control of the notification lights.
All other ROMs that have notification lights are likely using the original Motorola library, which doesn't work against LineageOS 13.
So the best I can do is get a green, solid LED to work as a notification light by using the LineageOS 13 "lights.msm8960.so" library for the Moto-X (ghost) platform. By replacing our file with the one from the Moto-X and modding the "framework-res.apk" to enable access to notifications we can gain access to the charging led and use natively for charging status and/or notifications.
Again though, you only get green and it's not going to blink.
For this to be corrected, someone with more knowledge is going to have to take a good, hard look at the obake's /liblight/lights.c file and add some control mechanisms for /sys/class/leds/red, green, blue, and red/blink.
Attached is the TWRP flashable zip.
Retracted.
I should have tested more thoroughly before I posted. Notifications work, but only if the device is plugged in.
I'm going to have to do some more trigger testing to figure out how to make it work when unplugged as well.
The problem with notifications is the library used to control the LEDs.
There's no good source code that I could find that allows for proper control of the notification lights.
All other ROMs that have notification lights are likely using the original Motorola library, which doesn't work against LineageOS 13.
So the best I can do is get a green, solid LED to work as a notification light by using the LineageOS 13 "lights.msm8960.so" library for the Moto-X (ghost) platform. By replacing our file with the one from the Moto-X and modding the "framework-res.apk" to enable access to notifications we can gain access to the charging led and use natively for charging status and/or notifications.
Again though, you only get green and it's not going to blink.
For this to be corrected, someone with more knowledge is going to have to take a good, hard look at the obake's /liblight/lights.c file and add some control mechanisms for /sys/class/leds/red, green, blue, and red/blink.
Retracted.
I should have tested more thoroughly before I posted. Notifications work, but only if the device is plugged in.
I'm going to have to do some more trigger testing to figure out how to make it work when unplugged as well.
Last edited:
Hi, here are these files from notz76 for CM12.1 wrote, it must be something!))) https://yadi.sk/d/XFNbSxMF3GPGZV
Thanks, but those files won't work. Instead, I had to hunt down some examples from other ROMs, then build an entire dev environment in a VM and get the symbols working so I could build my test code. Which works.
So, attached at the bottom is a working, TWRP flashable zip that contains a modified "/system/framework/framework-res.apk" and a new "/system/lib/hw/lights.msm8960.so" that actually works for color settable, blinking controllable notification and battery status lights.
(Apparently, the Moto-X only has a single LED, so it may not work for that one after all. It depends on what happens when you dump values into "/sys/class/leds/[red],[green],[blue]/brightness".)
If anyone knows how to get code pushed into the Lineage OS cm-13 tree for obake and ghost, please send me a PM.
EDIT: I no longer recommend using this zip. I have posted a complete ROM instead, but I leave the option here if you choose to use the notz rom. I will also not be updating these installer zips separately.
Last edited:
Also, for those who would like to incorporate this into other ROMS, here's the code for lights.c
https://github.com/pbarrette/android_device_motorola_obake/blob/cm-13.0/liblight/lights.c
https://github.com/pbarrette/android_device_motorola_obake/blob/cm-13.0/liblight/lights.c
Last edited:
Hi otmitia,
I was possibly a bit terse in saying that those files won't work. The code in your attachments will light up the RGB notification LED's. The problem with it is that it has some unchecked bounds on input and doesn't ramp the blinks. The input handling isn't really an issue, since it's getting its values from a trusted source (system), but I prefer the softer ramp up/down on the blinking.
The code you provided is doing the blinking here:
PHP:
write_int_int(RED_BLINK_FILE, onMS, offMS);The version I'm using is doing the blinking like this:
PHP:
// lit(ms), unlit(ms), ramp up,ramp down, blink.
sprintf(breath_pattern,"%d %d 1 1 1",onMS,offMS);
write_str(RED_BLINK_FILE, breath_pattern);I compiled the code you provided and have attached a "lights.msm8960.so" file below.
It's not a flashable zip, so if you want to test it, you'll have to push it into "/system/lib/hw/" manually.
I will definitely try but for now on CM12.1, and on CM12.1 will work or need lineage-13.0?
At me the request, in an investment with CM 12.1 he at me the same without light-emitting diode notices, add in it please the dross that at me the diode has earned, thanks!
Last edited:
pbarrette
You with such knowledge need to collect a completely fresh and working version based on lineage-13.0-20170624-nightly-ghost, only for Obake!:good:
I still have the last CM13 from the notz76 with LED notification, it can come in handy, it worked like clockwork!) https://yadi.sk/d/CfJ1td8x3KWNGA
You with such knowledge need to collect a completely fresh and working version based on lineage-13.0-20170624-nightly-ghost, only for Obake!:good:
I still have the last CM13 from the notz76 with LED notification, it can come in handy, it worked like clockwork!) https://yadi.sk/d/CfJ1td8x3KWNGA
Last edited:
Hi otimitia,
In order to compile the lights library, that's exactly what I had to do. I'm actually running my compiled ROM on my Mini right now to make sure it's stable and I'm waiting on approval for a dev account on AndroidFileHost for hosting space.
But, yeah, since I had to build a complete image just to get a single lib, I figured that I would contact notz and see if he wants to update the first page or have me start a new thread. Either way, I'll share the image soon. Since I use the phone myself, I'll probably do updates every couple months until I stop using the phone.
There's also still a problem with the notification lights that I just noticed today and exists in both versions of the code.
Both versions of the code write to the blink file as the last operation. We expect to set zero's if it's supposed to be a solid light and set msOn/msOff if it's going to be blinking. You have to set blink last because a write to the brightness file resets the blink.
The problem is that any call to blink, either with zero's or values, overrides the brightness setting. So, you can either set the brightness, or you can have blinking. Additionally, the Lineage code doesn't set msOn and msOff to zero in the "no blink" case. Instead, it sets msOn=1 and msOff=0, which is basically telling it to blink with a 1ms on time and no off time. That's confusing as hell and, IMHO, bad practice.
So I'm going to have to rewrite the code to account for those behaviors, keeping in mind that any calls for blinking notification lights also get no brightness adjustment. There's probably a way to have the library run a blink loop in software, but that's a lot of CPU just for a blink with variable brightness and probably isn't worth the effort when we already get full brightness blinking with ramp up/down for free in hardware.
In order to compile the lights library, that's exactly what I had to do. I'm actually running my compiled ROM on my Mini right now to make sure it's stable and I'm waiting on approval for a dev account on AndroidFileHost for hosting space.
But, yeah, since I had to build a complete image just to get a single lib, I figured that I would contact notz and see if he wants to update the first page or have me start a new thread. Either way, I'll share the image soon. Since I use the phone myself, I'll probably do updates every couple months until I stop using the phone.
There's also still a problem with the notification lights that I just noticed today and exists in both versions of the code.
Both versions of the code write to the blink file as the last operation. We expect to set zero's if it's supposed to be a solid light and set msOn/msOff if it's going to be blinking. You have to set blink last because a write to the brightness file resets the blink.
The problem is that any call to blink, either with zero's or values, overrides the brightness setting. So, you can either set the brightness, or you can have blinking. Additionally, the Lineage code doesn't set msOn and msOff to zero in the "no blink" case. Instead, it sets msOn=1 and msOff=0, which is basically telling it to blink with a 1ms on time and no off time. That's confusing as hell and, IMHO, bad practice.
So I'm going to have to rewrite the code to account for those behaviors, keeping in mind that any calls for blinking notification lights also get no brightness adjustment. There's probably a way to have the library run a blink loop in software, but that's a lot of CPU just for a blink with variable brightness and probably isn't worth the effort when we already get full brightness blinking with ramp up/down for free in hardware.
pbarrette I fully support you in your endeavors, and expect from you corrected Lineage OS
Update:
Blinking does, in fact, work with dimming. The problem was that any time any color value gets set to zero, the blink is reset, even if other colors are still lit. So it was tricky to find.
Basically, the code now zero's all the colors, then sets the new color, then sets the blink pattern.
I also decided to go with the more simplified code and dropped the idea of doing proper color mixing with LAB values since the RGB LED itself is pretty poorly constructed, so you'll never get exact non-primary colors anyway.
I also, arbitrarily, decided that blinks will fade in and out. That's a personal choice. If the user interface had buttons to control fade-in and fade-out, I could change the code to let the user decide. But there are no UI controls for that. And I happen to like the fade-in/out.
Next, I figured out some basic github and created a fork of notz's code and a pull request to try to get it back up the stack into the main Lineage OS repository. I'm not sure how github handles pull requests, so I don't know if the LOS team also gets notified, since his project is a fork from LOS's repository. I'll give it some time and see where that goes.
I've pushed three fixes upstream:
1 - Fix notification lights.
2 - Fix thermald conf files.
3 - Enable sending and receiving Mms when mobile data is disabled.
Number 3 is in the ghost repo from this commit, so I'm assuming it works on obake as well, but I'll admit that I haven't had a way to test it.
Finally, I have a pair of flashable LOS-13 zips at androidfilehost.
One is not rooted, but can be rooted by flashing the LineageOS 13 root installer package.
The other has root baked in already.
The code can be found in my github repo.
All standard disclaimers apply. Warranty void, Phone Bricks, House Burns Down, etcetera.
Blinking does, in fact, work with dimming. The problem was that any time any color value gets set to zero, the blink is reset, even if other colors are still lit. So it was tricky to find.
Basically, the code now zero's all the colors, then sets the new color, then sets the blink pattern.
I also decided to go with the more simplified code and dropped the idea of doing proper color mixing with LAB values since the RGB LED itself is pretty poorly constructed, so you'll never get exact non-primary colors anyway.
I also, arbitrarily, decided that blinks will fade in and out. That's a personal choice. If the user interface had buttons to control fade-in and fade-out, I could change the code to let the user decide. But there are no UI controls for that. And I happen to like the fade-in/out.
Next, I figured out some basic github and created a fork of notz's code and a pull request to try to get it back up the stack into the main Lineage OS repository. I'm not sure how github handles pull requests, so I don't know if the LOS team also gets notified, since his project is a fork from LOS's repository. I'll give it some time and see where that goes.
I've pushed three fixes upstream:
1 - Fix notification lights.
2 - Fix thermald conf files.
3 - Enable sending and receiving Mms when mobile data is disabled.
Number 3 is in the ghost repo from this commit, so I'm assuming it works on obake as well, but I'll admit that I haven't had a way to test it.
Finally, I have a pair of flashable LOS-13 zips at androidfilehost.
One is not rooted, but can be rooted by flashing the LineageOS 13 root installer package.
The other has root baked in already.
The code can be found in my github repo.
All standard disclaimers apply. Warranty void, Phone Bricks, House Burns Down, etcetera.
pbarrette
Many thanks! How to stitch, as usual? What TWRP?
Is it still good to add Motorola chips, Active display?)))
Another question: Did you check if hands free work in the car on bluetooth? And I have not yet worked on connecting to the WiFi block ELM327?
But it did not work on the latest build from notz76!
Many thanks! How to stitch, as usual? What TWRP?
Is it still good to add Motorola chips, Active display?)))
Another question: Did you check if hands free work in the car on bluetooth? And I have not yet worked on connecting to the WiFi block ELM327?
But it did not work on the latest build from notz76!
Last edited:
Hi Omitia,
This ROM is applied as any other ROM.
I first installed Notz76's LineageOS-13 ROM after a full wipe. After that, I have done dirty flashes of my own ROM with no problems.
So the standard disclaimer applies: A proper install requires a full wipe.
You may be able to go from CM-12 to LOS-13 without a full wipe, but I have not tried that, so I don't know if that will work or not. If you have Notz's LOS-13 installed, you can flash my image with no data loss, based on my experience.
1. - Moto Active Display is heavily dependent upon proprietary Motorola libraries and hardware integration. I don't think any 3rd party developer is going to be able to get it working.
2. - My car doesn't have built-in bluetooth, but I have no problems connecting to my Motorola Elite Flip headset, or my Dell XPS-13 laptop.
3. - Other than the 3 fixes noted above, I have not changed anything else in this ROM. Literally, my code only changes; notification lights, thermald configuration and, possibly, the ability to send MMS over WiFi.
I use TWRP 2.8.4 from this post by Skrilax_CZ:
https://forum.xda-developers.com/droid-ultra/development/twrp-2-8-4-0-droid-mini-ultra-maxx-t3012851
I suspect that any version of TWRP for obake or ghost will work, but I cannot guarantee that.
I have a version of cm-12.1-20150620-NIGHTLY-obake where Active Display works and literally the next version of cm-12.1-20150629-NIGHTLY-obake where it was removed, can it help?
I myself am sitting on cm-12.1-20150620-NIGHTLY-obake, because I really like Active Display
Your assembly will be delivered only tomorrow.
Last edited:
I looked at the code and it appears that "Ambient Display" is there. The toggles also exist in Settings->Display and Settings->Gestures.I have a version of cm-12.1-20150620-NIGHTLY-obake where Active Display works and literally the next version of cm-12.1-20150629-NIGHTLY-obake where it was removed, can it help?
I myself am sitting on cm-12.1-20150620-NIGHTLY-obake, because I really like Active Display
Your assembly will be delivered only tomorrow.
So I enabled them and.. they sometimes work and sometimes don't. My logcats show that it's sometimes getting called and sometimes not. Often, even when the logcat tells me that the screen was turned on via Ambient Display, my screen remains off.
It may be because I have the Mini which is LCD and not OLED.
The sensors are being read and the wakeup being done in the kernel code. I don't know enough to try hacking away at that.
Hello pbarrette! Put your lineage-13.0-20170628-UNOFFICIAL-obake-root. Excellent work, everything got up and works fine! The only thing that did not check this work in the car! Not enough Active display
But in general it's very cool! :good:Thank you.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone