yashsingh1/xdaforums huggingface dataset:
[Essential Phone ROMs, Kernels, Recoveries, & Other] rignfool:
There is something with properties in the init scripts...

Iirc lineage does the thing where it goes to noop on screen off...

If that's the case... In one of the scripts there is a property you can change before making it an image where you can set the scheduler... Otherwise it'll default out based on those settings
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Hm.. interesting, I did not know that. I was trying to make heads or tails of the lineage defconfig which sets noop as default versus that fact that BFQ was being applied on boot. I just assumed their init script was overriding the default kernel config.

Right after I posted that, I did manage to figure out that I could set maple on boot via magisk service.d (or init.d) script by coding in a 30 second delay before the script is executed. I imagine that this causes it it wait until after Lineage applies BFQ and then overrides it similar to how something like KA would apply saved configs on boot.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
***ANNOUNCEMENT***

Due to some extracurricular development, this project is beginning to expand beyond the scope of what I'd feel comfortable labeling a "stock" kernel, despite it's origins. I now stand at a fork in the road, and I can envision proceeding in one of two ways. Right now, I'm maintaining two concurrent branches one being an upstreamed pure stock configuration, and another in which some additional features and functionality are creeping into. Most, if not all of these changes will be in the interest of increased efficiency as well as overall performance provided the later does not impede the former.

As of the last few releases since the rebase, I've been letting some of these additions slip in but at a certain point we're going to start entering 'custom' kernel territory, and that point is rapidly approaching. At the end of the day these are my personal kernels, and any additions will be made based on features which I find to be beneficial and who's reward outweighs any potential risk. I'm happy to share these with you guys, but at this time I'd like to present you with a possible option going forward:

Would you prefer if I continued to release pure stock builds along side evolving custom releases going forward?

I don't want to waste time doing builds that neither myself not anyone else is interested in using, so if you're content with the way things have been proceeding recently and don't have a problem with a few custom features sprinkled in here and there then great, I'll keep doing what I'm doing. I just wanted to put this out there, and get a feel for whether or not there are any of you who who would prefer to have the option of vanilla upstream builds. If there's a real desire for it, I will do my best to accommodate both.

I've also included a poll in the OP on the matter, if you would like to voice your opinion that way.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
Custom would be awesome :)
[Essential Phone ROMs, Kernels, Recoveries, & Other] BakedTator:
Man...it's your kernel! Whatever you see fit I'm good with...I'm using your kernel with RR and I couldn't be happier!

Do what you do homie. I'm sure we will all be happy with whatever you feel is best for your kernel!
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
:good: Awesome. I've also taken into account that since we've got a small handful of Lineage-based ROMs available for mata now that it may be a little off-putting for people such as yourself to be staring at "lineage" as their kernel version when they're on RR, etc. I know it'd drive my OCD through the roof anyway. So, between that and the continuing evolution of this project, I suppose it's time to come up with a rad kernel name..
[Essential Phone ROMs, Kernels, Recoveries, & Other] DAE1964:
May I suggest Octobot.?
[Essential Phone ROMs, Kernels, Recoveries, & Other] Ashwin Prabhunerurkar:
i would really appreciate a broader release which includes lineage, My RR release and even my future AOSPA Release under a super custom dope kernel

and your regular stock release

The stock lineage,RR kernel just isnt that good
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
If you're indeed working on AOSPA for this device, I'd be very interested to hear more about any progress you've made. I have a close friend, who some of you would probably recognize, that's been making some attempts at getting PA building for mata as well.

I've considered using zips instead of boot images to install these, but quite honestly I'm just not a huge fan of AnyKernel format and at this time I just don't see that there's enough ROM variance to where it would be required for increased compatibility. I'm also just of the opinion that it's a cleaner install to be able to avoid flashing TWRP entirely. That being said, if things change in the future I wouldn't be opposed to reconsidering.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Ashwin Prabhunerurkar:
i have my exams coming up so no time for now

but i will have aospa up and running in end of april

the main thing is i cant find any reviews for it for oreo so i dont know if its any better than rr
[Essential Phone ROMs, Kernels, Recoveries, & Other] DAE1964:
Regarding battery drain. For myself with Magisk installed it's very poor, I had kernel auditor with adaway and titanium backup installed and battery drain from 49% to 25% overnight. Without root it is very good, about 3% drainage.

Your kernel is great. Thanks.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Skripka:
Something more is going on beyond Magisk on your device. Even when the phone does its "refuse to deep sleep" thing, I don't burn 25% battery in screen off in 8 hours.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
I did, easily actually. With the Bluetooth bug my phone was draining crazy fast and getting really hot
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I would have to agree with [MENTION=4388555]Skripka[/MENTION], that is an absurd level of battery drain and I'm certainly not experiencing this with Magisk installed, which leads me to believe there are other forces at play here.

I mean, this is just a snapshot from this morning but my device is not having any issues with entering deep sleep with Magisk installed. Granted, I haven't released the pictured version to you guys but it's essentially exactly the same as the 123 release you did get with a name change.

Anyway, I've got 4.4.124 merged into source, building and testing. Will have make it available for you guys either later on tonight or tomorrow at the latest.
[Essential Phone ROMs, Kernels, Recoveries, & Other] DAE1964:
I'm not sure what it could be. Nothing is different other than the apps mentioned. I also disabled background activity for all.

I can live without Root anyway.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
I meant on earlier versions, sorry if I was unclear on that. I was just saying that I did have similar experiences. This version has been perfect for me however.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Oh, great! Sorry, yeah I must have misread you or merged a couple of posts together in my mind. Glad to hear it.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Skripka:
If it was just Magisk doing it, it would effect everyone.

That the phone is getting hot means an app has gone nuts and not only is the device not sleeping---it is locked in a high-power CPU state. I suspect Titanium Backup actually. With later versions of Android it got less stable....it also tended to hang up and burn CPU cycles accomplishing nothing on batch restore operations in particular. Don't mean to rag on the developer at all, it was an awesome app, but later versions of Android have made it rather moot.

Only way to know is to check Better Battery Stats or similar.

If it was Magisk doing it--your symptoms would be epidemic and a ton of us would be seeing this behavior.
[Essential Phone ROMs, Kernels, Recoveries, & Other] DAE1964:
Phone never gets hot it just drains quickly when it's rooted. I will try again next weekend to see if it works properly.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
It was the Bluetooth bug causing a lack of deep sleeping. I figured it out long ago. This was on my end anyway, not sure about the other users.

I use BBS for the record. It was a kernel wakelock related to Bluetooth. (WCNSS)

No issues with root, magisk or the like for me, however he could be using a problematic module perhaps?
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I have considered supporting [MENTION=947981]Lord Boeffla[/MENTION]'s wakelock blocker in these builds, not sure if it would be of any help in that particular circumstance, but it very well may. Haven't added this yet, but I may do so for the next release.

Don't have time to update and revise the OP once again at the moment, but for anyone that would like to get their hands on 4.4.124 early, you can find it here.

Will be moving these releases to GitHub in the future, as I've fully realized the potential of the tagging system and I think it's much more beneficial to be able to put these out with release notes, changelogs, and downloads all in one fell swoop within the source repository itself.

Will get everything 'officially' updated by tomorrow, until then for anyone that sees this, welcome to Neutrino Kernel.
[Essential Phone ROMs, Kernels, Recoveries, & Other] initguru:
[MENTION=6474612]return.of.octobot[/MENTION]

We already have been getting great benefits from your awesome work.

Users may prefer a close-to-stock kernel or a more feature-rich custom kernel.

IMO i just worry that it could be hard for you to maintain two repositories as you said it is an extracurricular work.

Totally up to you op. :)

---------- Post added at 04:29 AM ---------- Previous post was at 04:21 AM ----------

I also have asked you a few weeks ago if you can implement a wakelock blocker, I had also been suffering from some kernel wakelocks.

I tried and merged the wl blocker commits by myself, it works so well as expected.

It will be more than great if you support the wl blocker in your kernel.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
You're right. As of now, I've been maintaining a separate branch which is just the Lineage/OPM1.180104.092 base plus the linux-stable merges without any of the additional features I've since included. It's good to have for reference if nothing else. I may continue to run stock lineage upstream builds if there's a demand for it. If I go that route, priority will be given to Neutrino as it's the kernel that I'm actually using personally, but it shouldn't prove to be a huge deal if I end up doing both. I just don't want to waste my time doing them if folks seem generally happy with things as they are.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Skripka:
WL blocker might be cool.

Catch with futzing with any such functionality...it can do more harm than good. I tried playing with Franco's Naptime, as a kludge for the deep sleep bug, but ended up eating more battery than it saved.

Whatever you want to do mi amigo. Pleasing everyone is nice...but these projects can quickly become unpaid "jobs" that drive you nuts maintaining them.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
You're so right. That was one of the big reasons I started out doing vanilla builds, so I could just put them out and say it is what it is and that's that. If there's one thing I can promise it's that I'm not going to let this project get bogged down with extraneous features for the sake of pleasing everyone. At the end of the day you've got to maintain some aspect of selfishness or the end product is going to suffer for it. Y'all are free to make suggestions, but like I've said I've got a pretty good idea of what I would and would not like to see included in the future. I generally only have an interest in making additions that I feel actually have merit in terms performance vs. efficiency. I'm drawing much of my inspiration from the work guys like [MENTION=6842057]nathanchance[/MENTION] and [MENTION=5051294]frap129[/MENTION] have done with the Pixel 2, as I consider them both to be rather brilliant in their own right.

A great example would be over clocking. Generally, I think the concept is frivolous and often ends up doing more harm than good. I made the decision to bump the little cluster up one frequency step not for the sake of increased performance but because the theory is that it should encourage the cpu scheduler to bias towards little cores at high frequencies over big cores at low frequencies, which in turn could/should see an increase in power efficiency. Moral of the story is I won't be doing anything that I can't rationalize being for the greater good.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
This kernel is awesome so far. Using Bluetooth all day and it's barely even sipping battery.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Skripka:
Yea...neutrino is kicking butt.

The catch being...even with Kernel Adiutor running things, the minimum CPU clock setting doesn't like to stick long term. It wasn't obeying 230mHz last night on auto so I set it manually. Checked BBS this morning and it wasn't going below 300mHz again. The max CPU limit however is being obeyed.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
I've actually been trying to leave my kernels alone the last little bit, I find that tends to end up with better results.

I think what you're describing might be due to schedutil governor honestly, which I think kind of runs the show itself for the most part, assuming that's what you're using
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I was going to note this when I updated the OP, but since you mentioned it, it's nearly impossible to manually set frequency limits with this SOC, as noted I believe this is due to schedutil and/or msm_performance having a mind of it's own. You can do it, but the system will quickly override them.

I've noticed that kernel management apps such as EX and KA do not seem to be properly reporting the upper and lower frequency limits (i.e. it will show as being 1900 MHz/300 Mhz). However, I have the additional steps hardcoded as default and if you look at the time-in-state data in either app you will see that both 2035 MHz and 230 Mhz are being utilized despite what the app is reporting as min/max. The CPU underclock is hit pretty rarely, I suspect almost exclusively during screen off/idle. I will look into what, if anything, can be done to encourage the scheduler to take advantage of the lower step more often. The GPU underclock @ 180 MHz however, is used quite frequently and the new little cluster cap @ 2035 MHz is being significantly utilized, but not overused.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Skripka:
Hmm. Sucky. Yea the more I look, the more it seems the lower-limit only stays applied for maybe a minute before reverting and the SoC taking over. Looking at CPU states in BetterBatteryStats echos what KA is reporting. That 7 seconds listed in your plot is the time before the SoC overrode the setting. Use the phone normally the rest of the day, I doubt you'll see anything more than 7 seconds of 230mHz.

BUT...on the other side CPU underclocks seem to stick. Setting say a 2200mHz cap on the big seems respected (what can I say, I don't game beyond Exploding Kittens), whereas before doing the same duties it wold jump to the stock max (2500mHz)
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Best I can think to do is perhaps try and replicate this commit to try and force the min frequency via command line similarly to what was done with the silver core's 2035 MHz step. Seeing as the upper limit is being respected, it seems feasible that this could work. If it doesn't I may ditch the CPU underclock entirely.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
**OP updated for initial Neutrino Kernel release (4.4.124-andromeda)**

Changelog (Summarized):

Min/max backlight control, backlight dimmer

Fsync toggle (enabled by default)

Disable CRC check

Adreno idler for msm-adreno-tz

Underclock GPU @ 180 MHz

Underclock CPU @ 230 MHz

Overclock CPU (partial) silver cores @ 2035 MHz

Decrease low battery threshold 10% > 5%

Compile @ O3 optimization level

Full changelog available here.

*NOTE regarding new frequency limits: If you're using kernel management apps such as KA or EX, please refer to the time-in-state data to reference whether or not the new steps are being utilized. I've found, for instance, that these apps will still report a max frequency limit of 1900 MHz for the little cluster despite the fact that 2035 MHz is being used. It's more or less a futile effort to try and use these apps to limit cpu min/max frequencies on newer SOCs anyway as they will almost certainly be quickly overridden. For this reason, I'm doing my best to hardcode the additional steps as default. This seems to have been successful in terms of the silver core overclock and the GPU underclock which are both being effectively utilized without the intervention of kernel apps. The 230 MHz CPU step, while being recognized, seems as though it is still being overridden. I'm going to attempt to force this for the next release, otherwise I may revert that one in particular entirely.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
Any changes from version released yesterday?

Edited - nm I see it links to same file
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
It is the same as the one you would have downloaded yesterday, for anyone that did. I just got a little ahead of myself and put it out there before I updated the thread as I was a bit anxious to get neutrino out there but wasn't so keen on doing another thread revision. :p Consider this to be the 'official' release post.
[Essential Phone ROMs, Kernels, Recoveries, & Other] duminduweera:
Eagerly waiting for [MENTION=947981]Lord Boeffla[/MENTION]'s wakelock blocker :)
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
And I was anxious to flash obviously ?
[Essential Phone ROMs, Kernels, Recoveries, & Other] rignfool:
I am just a user... But here's my 2¢...

According to what I read from CAF... You should not use frequencies under 300 MHz...

You screw up either load balancing or load calculation... And unless your device sits idle in you pocket all day... You'll gain nothing...
[Essential Phone ROMs, Kernels, Recoveries, & Other] Tech_Savvy:
while ur up to taking suggestions.. would you consider added wireguard compatible
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I totally appreciate the insight, I'm not too far removed from being 'just a user' myself and you may very well be right. On the bright side, I'm having trouble enforcing the 230 MHz step anyway so worst case scenario it's doing absolutely nothing and thus I'm on the verge of reverting it anyway. May have gotten ahead of myself on that one. While on the subject, I am hoping to get this source up to date with the latest 8998 tags eventually, I was having some trouble with LA.UM.6.4.r1-06500-8x98.0 breaking input detection but I think I may have identified my misstep there.

Yeah as a matter of fact Wireguard support is something that's definitely on my radar. I may or may not get it in for the next release, but you definitely should expect to see it sooner than later.
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
So now that this is custom, are updates going to happen between kernel versions or still only when kernel version changes? Just curious, not asking for ETA's or anything like that.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Charles::
Just to clarify, I'd need to fastboot flash this kernel every time I also upgrade a new version of LOS? I'm assuming I would cause I'd need to get this kernel on the other boot slot with the new LOS version.

Also, pardon my ignorance, but is there no way to have Magisk install this on the other slot with each ROM update like it can with the GCam port? As it stands now, I can update to the newest LOS version, keep root, and install GCam port without the need to plug into a computer. It would be awesome if I could do that with an custom kernel too.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
It's a possibility, that's why I went with named subversions in case I ever push updates between Linux kernel versions or vice versa, but they update so frequently I'll probably release inline with linux-stable unless it's something really critical.

Yeah, you'll have to reinstall the kernel after each OTA. As far as installing a kernel goes, you'd either be flashing a zip via TWRP or flashing an image via fastboot and I'm of the opinion that it's much simpler in the case of this device to just boot to fastboot and flash the kernel directly rather than booting to fastboot, flashing TWRP, and then flashing a kernel zip. Just kind of cuts out an unnecessary middle man.

The thing is, when you install Magisk to second slot after OTA, it's taking the boot image of the ROM you just installed and patching it, so whatever's on the boot partition of your current slot is unfortunately irrelevant as far as Magisk is concerned. Whereas all of your modules and core magisk files exist in a shared space used by both slots, which is why they carry over between updates. It would be great to be able to do what you're suggesting, but that'd be on Magisk's end to implement the option to manually select a custom boot image when installing to second slot after OTA.
[Essential Phone ROMs, Kernels, Recoveries, & Other] killer86th:
My phone got 2 hot shutdown when I perform tasks with Essential camera, one time is when I was recording a clips, and one time is when I was viewing another clip (from Essential Camera app), sorry that I couldn't grab a log, I'm on latest 27 Mar LOS, 4.4.124 kernel, no root, no Gcam. Is anybody having the same issue?
[Essential Phone ROMs, Kernels, Recoveries, & Other] crixley:
Nothing like that here
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I went and tried recording some footage in various configurations with the essential camera after reading this and couldn't trigger anything of that nature. If it's a recurring problem and/of something you feel you can reproduce on your own device I would recommend capturing a log, otherwise I'd be speculating at best as to what might be going on.

On a separate note, I am aware that 4.4.125 has been released. You're going to have to bare with me for a day or two on that one pending on the results of some testing in which I am currently knee deep.
[Essential Phone ROMs, Kernels, Recoveries, & Other] killer86th:
Thank you for taking your time to look into this, I will continue to monitor and try to get a log should it happen again :good:
[Essential Phone ROMs, Kernels, Recoveries, & Other] bokononfoma:
I am also experiencing no deep sleep when using Bluetooth (particularly my Android Wear watch). This is on LOS using the built in kernel or neutrino kernel .122, .123 or .124. The phone will sleep for portions of the first hour or so after a reboot. But then it will not sleep at all until another reboot.

As an aside, I noticed that stock Oreo 8.0 betas 1 and 2 had the same problem. But beta 3 did not. I have not tried stock 8.1.

Has anyone found a solution?

Loving neutrino.