[ROM] [7.1.x] LineageOS 14.1 OFFICIAL Builds (ether)

[jabashque]

The 15.1 LOS unofficial rom appears to be a bit sluggish scrolling between screens with over 1.2GB of memory left over and not too many apps running. Am I the only one?

Just came from a Pixel but could not resist having this phone again. So awesome.

(Might want to keep in mind that the most recent build javelinanddart posted defaults to running the display at 45Hz. If you run `setprop persist.sys.display.frame_rate 2` in a root or adb shell, you can change the framerate back to 60Hz.)

 

[michaelmcnutt]

The 15.1 LOS unofficial rom appears to be a bit sluggish scrolling between screens with over 1.2GB of memory left over and not too many apps running. Am I the only one?

Just came from a Pixel but could not resist having this phone again. So awesome.

Try the LOS based Oreo ROM from @firebird11 CRDroid, I find it to be smooth and stable, with nice extras and great battery life.

 

[shunjou]

(Might want to keep in mind that the most recent build javelinanddart posted defaults to running the display at 45Hz. If you run `setprop persist.sys.display.frame_rate 2` in a root or adb shell, you can change the framerate back to 60Hz.)

Can't speak for that guy, but I wasn't running the last posted build. I ran a new build initially, purely from last available official sources, since I didn't like the baked in gapps/su or the weird icons. The hacky custom power hal just has too many issues.

 

[jabashque]

Can't speak for that guy, but I wasn't running the last posted build. I ran a new build initially, purely from last available official sources, since I didn't like the baked in gapps/su or the weird icons. The hacky custom power hal just has too many issues.

Ah, I see. Could you clarify what sort of issues the custom power hal had, just out of curiosity?

 

[shunjou]

Ah, I see. Could you clarify what sort of issues the custom power hal had, just out of curiosity?

I think I already explained it. The lag was excessive. Feedback from the change is already positive in the omni thread.

 

[jabashque]

I think I already explained it. The lag was excessive. Feedback from the change is already positive in the omni thread.

I meant that as in "what particular tweaks in the custom power hal were causing the lag", though I didn't really make that clear in my previous post.

 

[shunjou]

I meant that as in "what particular tweaks in the custom power hal were causing the lag", though I didn't really make that clear in my previous post.

Diff the power init scripts and you'll see the changes. I didn't review every line, but it's easy to tell that it's less of a mess. I'm not even the one that authored the commit. I think the main issue was that the big cores weren't turning on reliably or utilizing a greater freq range when they were. I think the governor could definitely use some tuning to improve battery life a bit, but otherwise I can't see your argument that it isn't an improvement. If you have any suggestions, I'd love to hear them.

 

[jabashque]

Diff the power init scripts and you'll see the changes. I didn't review every line, but it's easy to tell that it's less of a mess. I'm not even the one that authored the commit. I think the main issue was that the big cores weren't turning on reliably or utilizing a greater freq range when they were. I think the governor could definitely use some tuning to improve battery life a bit, but otherwise I can't see your argument that it isn't an improvement. If you have any suggestions, I'd love to hear them.

Oh, no, I am finding my experience to be overall smoother on Omni with the CAF power hal, but I wanted to know if you were able to narrow down what tweaks were causing the issues. I remember that javelinanddart had pulled in a bunch of tweaks from the sambar (Yu Yutopia) device tree for the Lineage power HAL and was trying to figure out how he could squeeze more battery life out of his Robin.

As for the big cores, well, you didn't change anything in configs/thermal-engine-8992.conf, where javelinanddart had lowered the temperature thresholds for when to turn off the big cores, so the big cores are still unplugging pretty quickly whenever any significant CPU activity is happening.

 

[shunjou]

As for the big cores, well, you didn't change anything in configs/thermal-engine-8992.conf, where javelinanddart had lowered the temperature thresholds for when to turn off the big cores, so the big cores are still unplugging pretty quickly whenever any significant CPU activity is happening.

I don't think anything is wrong with the thermal throttling. From what I've observed, the big cores turn off when the little cores run at max freq for a certain amount of time, otherwise they most often idle at the lowest freq. I haven't experienced any lag with this behavior. Previously, the little cores were remaining at max freq much more often which kept the big cores from idling on at all. This commit may also have had something to do with it.

 

[jabashque]

I don't think anything is wrong with the thermal throttling. From what I've observed, the big cores turn off when the little cores run at max freq for a certain amount of time, otherwise they most often idle at the lowest freq. I haven't experienced any lag with this behavior. Previously, the little cores were remaining at max freq much more often which kept the big cores from idling on at all. This commit may also have had something to do with it.

I hadn't observed that big core behavior back on the Nougat-based roms. Instead, I'd end up seeing both the little cores and big cores being slowed down (787MHz for the little cores, 384MHz for the big cores), but the big cores never being shut off.

For what it's worth, on Omni 8.1.0, I went and outright deleted /system/etc/thermal-engine-8992.conf, restarted, killed perfd, then set min big CPU to 2 and set all 6 cores to their highest clockspeeds (1440MHz for little, 1824MHz for bit), and none of the big cores have shut off after a few minutes. The cpus do slow down their clockspeed when I proceed to do any heavy CPU activity, but otherwise, the big cores don't shut off.

Also, to address you thinking that the big cpus not turning on reliably was the main issue: even with the big cpus still not really remaining on, I still have a smoother experience with the CAF power HAL on Omni. There are too many differences in code style between the old power init scripts and the CAF ones though, so I can't really just diff them to see what's different.

EDIT: I only meant to ask you if you knew what specific changes javelinanddart made that cause performance issues, not to try and prove you wrong or anything like that; sorry about that. When I talk about my experience on Omni being smoother, I meant that as in whenever I wake my phone from sleep, I don't have to worry about my phone possibly lagging to hell and back for maybe 5 to even 30 seconds because of heavy IO activity, unlike on the Lineage nightlies. I suspect that the slowdowns and lagginess you're referring to is not the slowdowns and lagginess I had in mind.

 

[shunjou]

I hadn't observed that big core behavior back on the Nougat-based roms. Instead, I'd end up seeing both the little cores and big cores being slowed down (787MHz for the little cores, 384MHz for the big cores), but the big cores never being shut off.

I'm not sure why you're bringing up your experience in N. I think what you said here is in response to an O build? What you said there describes the behavior I mentioned before fairly well.

For what it's worth, on Omni 8.1.0, I went and outright deleted /system/etc/thermal-engine-8992.conf, restarted, killed perfd, then set min big CPU to 2 and set all 6 cores to their highest clockspeeds (1440MHz for little, 1824MHz for bit), and none of the big cores have shut off after a few minutes. The cpus do slow down their clockspeed when I proceed to do any heavy CPU activity, but otherwise, the big cores don't shut off.

If you set ro.core_ctl_min_cpu to 2 that would imply that they'd stay on. I don't know why this wasn't the case in your old post I linked, but what you're saying now makes sense.

even with the big cpus still not really remaining on, I still have a smoother experience with the CAF power HAL on Omni. There are too many differences in code style between the old power init scripts and the CAF ones though, so I can't really just diff them to see what's different.

The big cores do remain on now, idling at lowest freq, and turn off momentarily when the little cores are fully stressed for long enough. If this is a result of the thermal throttling, then I don't see a reason to change it. I'm not sure if it's any different in omni. The only major difference in style I can see is that the caf hal script uses echo instead of write, otherwise they are comparable in the values they assign.

Overall, I'm not sure what you're trying to get at here. What exactly was wrong with the old power hal? Dunno, couldn't tell you, but I doubt anyone could right now since it likely wouldn't have still been an issue. Why spend the time to find an exact fault with a complex part when you can simply replace it with far less effort and get the intended result? You should probably ask the omni maintainer for more info, since he's the one that originally saw fault with it as far as I can tell.

When I talk about my experience on Omni being smoother, I meant that as in whenever I wake my phone from sleep, I don't have to worry about my phone possibly lagging to hell and back for maybe 5 to even 30 seconds because of heavy IO activity, unlike on the Lineage nightlies. I suspect that the slowdowns and lagginess you're referring to is not the slowdowns and lagginess I had in mind.

I think we're talking about the same thing. Even on 14.1, the fingerprint scanner would be a bit sluggish. Now it feels more responsive than it's ever been. Still just as annoyingly inaccurate though.

 

[jabashque]

I'm not sure why you're bringing up your experience in N. I think what you said here is in response to an O build? What you said there describes the behavior I mentioned before fairly well.


If you set ro.core_ctl_min_cpu to 2 that would imply that they'd stay on. I don't know why this wasn't the case in your old post I linked, but what you're saying now makes sense.



The big cores do remain on now, idling at lowest freq, and turn off momentarily when the little cores are fully stressed for long enough. If this is a result of the thermal throttling, then I don't see a reason to change it. I'm not sure if it's any different in omni. The only major difference in style I can see is that the caf hal script uses echo instead of write, otherwise they are comparable in the values they assign.

Overall, I'm not sure what you're trying to get at here. What exactly was wrong with the old power hal? Dunno, couldn't tell you, but I doubt anyone could right now since it likely wouldn't have still been an issue. Why spend the time to find an exact fault with a complex part when you can simply replace it with far less effort and get the intended result? You should probably ask the omni maintainer for more info, since he's the one that originally saw fault with it as far as I can tell.

Yeah, that was why I ended up adding in the EDIT in my previous post after I realized that I didn't really know what I was trying to achieve at the end, especially when you were referring to overall lagginess when interacting with the phone in general and not just when waking the phone up. Sorry about the trouble.

EDIT: It wasn't just the fingerprint scanner that was lagging. Anytime the lag happened, all the UI elements would lag to hell and back too, and it would continue to be that way until all the background I/O activity finished (checked in iotop) . Even then, I don't know if that issue I had with Lineage 15.1 was something that happened only to me, as I hadn't set aside time to clean flash Lineage again to see if it persisted.

 

[namikiri]

Hi guys. I don't know where to post so correct me if I'm wrong.

TL;DR: I want to fix left and right audio channels by swapping them. What should I do?

Recently I flashed latest LOS Nightly. As you know our Robin has two microphones and two speakers. And LOS uses them wrongly!
Usually when you want to use your phone in landscape orientation you turn your phone in 90 degrees counter-clockwise.
So the top speaker and corresponding mic become left ones.

But they are used by Lineage as right! Audio from the top mic is recorded into the right channel and the right channel of your music is played on the top speaker. That's wrong I guess, so I decided to try to fix it. I use /system/etc/mixer_paths.xml and /system/etc/audio_platform_info.xml file to set up correct routes.

What I want:

• Swap mic channels for video recording
• Swap speaker channels
• Use both microphones when using vocie recorders, as it was in stock ROM.

I could do only the first.
First, I defined the new path and called it "camcorder-dmic-endfire". It's just a copy of "handset-dmic-endifire" with DEC10 and DEC7 swapped.

    <path name="camcorder-dmic-endfire">
        <ctl name="AIF1_CAP Mixer SLIM TX7" value="1" />
        <ctl name="AIF1_CAP Mixer SLIM TX8" value="1" />
		
        <ctl name="SLIM TX7 MUX" value="DEC10" />
        <ctl name="DEC7 MUX" value="DMIC1" />
		
        <ctl name="SLIM TX8 MUX" value="DEC7" />
        <ctl name="DEC10 MUX" value="DMIC3" />
		
        <ctl name="SLIM_0_TX Channels" value="Two" />
    </path>

Then I corrected audio_platform_info.xml as follows:

    <device_names>
        <device name="SND_DEVICE_IN_VOICE_DMIC" alias="voice-rec-dmic-ef-fluence" />
        <device name="SND_DEVICE_IN_CAMCORDER_STEREO_DMIC" alias="camcorder-dmic-endfire" />
        <device name="SND_DEVICE_IN_VOICE_REC_DMIC_STEREO" alias="camcorder-dmic-endfire" />
    </device_names>

It worked and now I have top mic as left channel and bottom as right.

But I'm stuck with swapping the speakers and mixing both mics into a single channel for voice recording. How to do it? Who can help me with understanding of these files and tell how to do what I want?

When you start recording your voice using any app, a path called handset-mic is used. In the XML file it refers to dmic1. How to make it to use both mics?

Lineage's mixer_paths for ether can be found on GitHub

 

[witnit]

I recently flashed Lineage for the first time on my Robin. One issue I ran into is with the speakerphone. Regardless of how low I turn the volume, it still seems to be quite loud, so much so that the person I'm talking to can hear an echo of their own voice. Are others of you experiencing this same issue?

My installation:
* lineage-14.1-20180425-nightly-ether-signed.zip
* open_gapps-arm64-7.1-nano-20180423.zip
* Not Rooted

 

[hairycheez]

I recently flashed Lineage for the first time on my Robin. One issue I ran into is with the speakerphone. Regardless of how low I turn the volume, it still seems to be quite loud, so much so that the person I'm talking to can hear an echo of their own voice. Are others of you experiencing this same issue?

My installation:
* lineage-14.1-20180425-nightly-ether-signed.zip
* open_gapps-arm64-7.1-nano-20180423.zip
* Not Rooted

Yea think it's been like that for a while. Never use speakerphone tho so

 

[freddd1]

What is the struggle to push out 15.1?

 

[malerocks]

What is the struggle to push out 15.1?

Nobody is working on it.

 

[malerocks]

Guys, I have the latest 14.1 rom on my Robin. No root. I am facing a issue ever since I flashed the rom a month ago. Whenever I am on a call, if I am using the loud speaker the other person is not able to hear me after a few minutes. Only think that fixes it is a reboot but the same thing happens again after a while. There is also a weird disturbance.

Any suggestions how I can fix it.

 

[Zen12]

Solution

Yup. The charging LED that works on stock ROM and I flashed the latest arm64 OpenGapps pico.

For anyone still searching for an answer, go in settings>notifications>gear button and lower the light brightness completely then turn it back on.then enable and disable notification light

 

[ted583]

LineageOS 14.1 is a free, community built, aftermarket firmware distribution of Android 7.1.x (Nougat), which is designed to increase performance and reliability over stock Android for your device.



LineageOS is based on the Android Open Source Project with extra contributions from many people within the Android community. It can be used without any need to have any Google application installed. You will need to provide your own Google Applications package (gapps). LineageOS does still include various hardware-specific code, which is also slowly being open-sourced anyway.

All the source code for LineageOS is available in the LineageOS Github repo. And if you would like to contribute to LineageOS, please visit our Gerrit Code Review. Your changelog is whatever was merged into gerrit.

Other Issues Not in Known Issues?

Before posting on this thread, make sure of a few things:
You've utilized the search function of the forums. Nothing irritates me more than lazy people who do not search for an answer before asking or ask the same question over and over again.
If you are the only one having a problem. Boot into recovery, wipe data/factory reset, reflash the rom/gapps and nothing else. Boot up and see if the problem persists.
LOGS LOGS LOGS!!!! Use this: SysLog by Tortel

If you have a hard reboot (to the vendor boot logo, not the LineageOS boot logo), use adb or any other file explorer tool to pull a copy of

/sys/fs/pstore/console-ramoops (command: adb pull /sys/fs/pstore/console-ramoops)
/sys/fs/pstore/console-ramoops-0 (command: adb pull /sys/fs/pstore/console-ramoops-0)

after the reboot and provide that (or just get everything in that directory).

Note: We will not support any kind of modification on the ROM not done by our sources. If you are running XPosed, Kernel Booster or whatever occurs to you, we won't support you in any way. The problem will in every case be treated as the additional softwares' fault (because often it is!)

Google apps addon:
We are using Open GApps (Link) Arm64 version. (make sure to use 64bit when using other packages), others might also be working and make sure you download the right version. I do not recommend stock or full or anything that replaces default apps as this has been known to cause problems (e.g. replacing the dialer with a stock dialer can make it crash).

Note: In case you want to use any gapps, YOU MUST install the right gapps the first time that you flash a marshmallow or later ROM. Do not boot with an older gapps or without one and then try to install it later.
Note: If you install a package which replaces the default dialer (mostly "Stock Gapps") you have to go to Settings->Apps->Gear-Icon and set the new dialer as a default telephony app to prevent force closing of apps

Known Issues

None that I am aware of.


If you encounter any other issues, please let me know by filing a bug in JIRA with:

logs
steps to reproduce
carrier
firmware: stock M or N as your last RUU/official update


problems reported without all of this information will usually be ignored and even occasionally flamed...

Download

Instruction: Instructions
Download: LineageOS download site

Changelog

https://www.cmxlog.com/14.1/ether

XDA:DevDB Information
LineageOS 14.1, ROM for the Nextbit Robin

Contributors
crpalmer, chrmhoffmann, mikeionnia
Source Code:https://github.com/LineageOS/android_kernel_htc_msm8996

ROM OS Version: 7.x Nougat

Version Information
Status: Nightly

Created 2017-05-07
Last Updated 2017-05-07

I can't find access point in settings is this available for this room?