yashsingh1/xdaforums huggingface dataset:
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Unfortunately I don't have time at the moment to throw together an official release post and update the OP of this thread, that will have to come later. I'd rather not keep you all waiting any longer than I already have, so in the meantime, the new drop has been uploaded to GitHub.

I'd recommend that anyone who's genuinely interested in what's gone on since the previous release peruse the full commit history and staging repo as the differences are much more extensive than I can do justice in a brief outline, and the listed 77 commits since the last release are extremely misleading.
[Essential Phone ROMs, Kernels, Recoveries, & Other] gregfink83:
Working great on Los so far! Thank you again
[Essential Phone ROMs, Kernels, Recoveries, & Other] aamadorj:
New Neutrino Kernel (equuleus) is working perfectly with the build from July 9th of AOSiP ROM. Thanks a lot for your dedication to provide an updated and refined kernel, [MENTION=6474612]return.of.octobot[/MENTION].
[Essential Phone ROMs, Kernels, Recoveries, & Other] kakabobo:
stune user tunable variable removed?
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I probably didn't word that as well as I could have. The problem was without being able to modify the ramdisk, our top-app, foreground, background, and rt stune boost parameters were being overridden thereby interfering with Dynamic SchedTune Boosting. These values are now hardcoded into the kernel source so that DSB can function properly without the need for ramdisk alterations. You can view the commit here. You should still be able to set the dynamic_stune_boost factor (which is 10 by default).

Sorry, for the confusion. I'll be going back to clean up the release notes and revise the OP by tomorrow. I was in a bit of a rush to throw everything together and get the release out this morning.
[Essential Phone ROMs, Kernels, Recoveries, & Other] innocentone1:
After testing this kernel out, this is literally the best kernel to date. Thank you so much octo!
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Thank you very much, I can't help but agree. I'm not particularly comfortable patting myself on the back, but I did sink some considerable time and effort into this latest so it's great to hear that it was all worthwhile.

I'm going to be working on the next update through the weekend, there's been some updates for Dynamic SchedTune Boosting that I'm going to have to figure out how to handle and a few other things. Now that I've established the new codebase I'm hoping to get releases out weekly-ish, or at least twice a month as needed.
[Essential Phone ROMs, Kernels, Recoveries, & Other] ::1:
Could we get kernel support for the Realtek RTL8822BU driver? I'd like to use my edimax wifi adapter via OTG. The PH1 is slowly replacing my main pentesting rig.

I see the odroid XU3 got this with LOS 14.1. Here are the kernel commits:

https://github.com/voodik/android_kernel_hardkernel_odroidxu3_beta/search?q=RTL8822BU&type=Commits
[Essential Phone ROMs, Kernels, Recoveries, & Other] droidian5:
The LineageOS Blog also has some good news on that front too concerning A/B support!

https://lineageos.org/Changelog-19/
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I'll definitely take a look into that for you.
[Essential Phone ROMs, Kernels, Recoveries, & Other] ::1:
I somewhat got it working on the stock kernel (I wanted to try stock first so I'd be changing as few variables as possible). Here's how I got the driver compiled into the kernel:

I had to comment out line 50 in /drivers/net/wireless/rtl88x2BU/core/rtw_debug.c which was causing a compile error:

RTW_PRINT_SEL(sel, "build time: %s %s\n", __DATE__, __TIME__);

I enabled monitor mode (line 66 in /drivers/net/wireless/rtl88x2BU/Makefile):

CONFIG_WIFI_MONITOR = y

My USB wifi device is detected in Kali linux (linux deploy). However, if I put the wlan interface directly into monitor mode, my phone freezes and reboots. I was eventually able to get monitor mode working by turning off the interface, putting it into managed mode, then monitor mode, then turning it on. I was able to see networks in airodump-ng and inject deauth frames with aireplay-ng.

However, I wasn't able to reproduce this success. It now either causes a reboot when I directly enable monitor mode, OR selinux denies access. In dmesg I see:

avc: granted { net_admin } for pid=1176 comm="lowi-server"
avc: denied { ioctl } for pid=16657 comm="iwconfig"

I'm still playing around with it to see if I can reliably get monitor mode working with this driver. I'm also testing kernel builds with other driver repos (they're intended for desktop, so it's somewhat more involved than the copy-paste from the odroid commits):

https://github.com/brandon-bailey/rtl8822bu
https://github.com/drwilco/RTL8822BU

I'll post an update if I figure this out. Once this works on stock, I'll likely submit a pull request on your neutrino repo.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Yeah absolutely, I was going to suggest opening an issue but since you're well on your way to cracking the case a pull request would be fantastic. Let me know how you make out with this.
[Essential Phone ROMs, Kernels, Recoveries, & Other] ranasrule:
is there an app that can be used to change the kernel settings ? Stuff like selection of governors and color settings?
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
I would recommend EX Kernel Manager. Kernel Adiutor would be another option if you'd rather not fork over any cash. As a caveat, I'd like to add that schedutil is really the only governor I'd recommend using as it was designed for use with EAS and offers the highest level of compatibility with what this kernel has to offer. Because I lack ramdisk support with the boot image release format, I make every effort to hardcode all relevant tunables for the best possible UX. That being said, you're obviously free to tweak to your hearts content. I just don't really want to hear about any complications you may be experiencing unless those complications are also present when using Neutrino's default settings.
[Essential Phone ROMs, Kernels, Recoveries, & Other] ranasrule:
Thank you for the reply. I mainly want to tweak color settings. Any app for that? Doesn't have to be free.
[Essential Phone ROMs, Kernels, Recoveries, & Other] Obamaloominaty:
EX Kernel Manager is the best for managing settings like this.
[Essential Phone ROMs, Kernels, Recoveries, & Other] ranasrule:
even on this kernel?
[Essential Phone ROMs, Kernels, Recoveries, & Other] Obamaloominaty:
Yeah, it's not just for ElementalX
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Yeah, I don't have to tweak much seeing that I'm writing the kernel but I personally use EX Kernel Manager. It's impressively universal and is very compatible in terms of what Neutrino offers. The app is also quite useful for monitoring CPU behavior and power consumption. You can certainly use it to adjust color profiles.

On an unrelated note, I'm making good headway hammering out the next release and it's shaping up to be a rather significant update. I know Essential just dropped a new P build based on Preview 5, I'm buying some time to see if they're going to push the new kernel source anytime soon but I'm not too worried about it as I can't imagine they've added too much that I haven't already included. Regardless, I hope to have it ready for this weekend or early next week at the latest.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
New release on track for tomorrow, ran through some test builds and got everything finalized today. The final release build is being cooked up as we speak.

You can preview some of the changes made since equuleus here.

I may as well take this opportunity to prep everyone, I have drastically overhauled our event-based CPU boosting framework and dropped Qualcomm's cpu-boost driver in favor of sultanxda's cpu_input_boost. I was hesitant to do this in the past because Dynamic SchedTune Boosting is natively dependant on the standard QCOM driver and I did not want to sacrifice that feature to accommodate sultan's implementation. This conflict has been remedied by adapting cpu_input_boost for compatibility with Dynamic SchedTune Boosting and everyone's happy. DSB itself has undergone substantial updates in and of itself, so there's a lot going on here. I'm sure I'll elaborate further on all of this at a later date, but for the time being I just wanted to give everyone a heads up as to what they can be expecting.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
**OP (partially) updated for Neutrino Kernel release (4.4.145-neutrino_fornax)**

I still need to revise our feature list at some point, but those of you who've been keeping up with these release notes should have a pretty good idea of what's been going on.

Changelog (Summarized):

Update to latest Essential P Beta (PPR1.180610.066)

kernel.lnx.4.4.r27-rel: Update to LA.UM.6.2.r1-09500-sdm660.0

Update WLAN drivers inline with android-p-preview-5_r0.2

EAS and Dynamic SchedTune Boosting updates from EAS-Project (PPR1.180610.066_eas)

Drop Qualcomm's cpu-boost in favor of sultanxda's cpu_input_boost driver

Adapt cpu_input_boost for compatibility with Dynamic SchedTune Boosting (PPR1.180610.066_sultan)

Tentatively drop stune_assist configuration driver

Additional build warning fixes and optimization flag improvements (PPR1.180610.066_clang)

Improve GCC compatibility and support compilation with versions ≤ 8.1.0 (PPR1.180610.066_gcc)

Adopt several mata-specific optimizations from YaroST12 (PPR1.180610.066_yaro)

Various arm64 and SOC-specific optimizations

Full changelog available here.

Notes regarding the new CPU Boosting framework.

Because I never officially posted them in this thread, here are the previous release notes for equuleus as well.

NOTE: If you're using EXKM, I would recommend uninstalling the app prior to flashing this update and then reinstalling it afterwards. I've ran into some issues with EXKM loading old default parameters which are no longer optimal and failing to recognize new defaults until the app has been reset following kernel updates with substantial changes to particular features, in this case our CPU boosting framework. If you don't do this prior to flashing, you can also uninstall, reboot, and then reinstall following kernel update. I don't know if this applies to other kernel management apps as well, but I suppose it wouldn't hurt.
[Essential Phone ROMs, Kernels, Recoveries, & Other] galakanokis:
Ha, just installed the previous one a couple of hours ago. Guess I will try this patched boot img install through magisk which I have never fine before. Really like following your work. I'll see his this runs.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
So, there's some detailed instructions in the OP about patching the release images for Magisk compatibility but it's pretty straightforward. Essentially, open Magisk Manager and select install until you're given the option to patch boot image. Then you can select the release image from it's download location and the patched image will output to the MagiskManager directory at the root of your sdcard. At this point, you can move the patched image to your PC and flash it via fastboot or you can flash it from your device using a terminal emulator if you already have root [see ADVANCED INSTALLATION (No Fastboot/PC) instructions in OP].
[Essential Phone ROMs, Kernels, Recoveries, & Other] galakanokis:
I read up already, your documentation and instructions are second to none. I am going to try the terminal emulator and see how it goes.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
NOTES: Regarding the new CPU Input Boost framework and updates to Dynamic SchedTune Boosting.

First and foremost don't panic when you see both cluster's minimum frequencies locked at their boost values during graphics intensive activities such as video playback/streaming and gaming. This is by design, sultan's driver calls for boost kicks every time a new frame is to be committed. While this may seem like overkill, it is actually more economic then having CPU frequencies jump around wildly under heavy load. Both cluster's will return to their true minimum frequencies as soon as the aforementioned activities have ceased.

I have set the default boost values based on the results of [MENTION=3292224]franciscofranco[/MENTION]'s testing on OP6, they may or may not need to be fine tuned for this device going forward. In the meantime, I have given you the ability to set the boost frequencies for both clusters although I wouldn't necessarily recommend messing around with them unless you have a pretty good idea of what you're doing. I have also reduced the default wake boost duration in an attempt to mitigate needlessly boosting CPU frequencies every time ambient display kicks the screen on.

I was previously using YaroST12's stune_assist driver to configure Dynamic SchedTune Boosting parameters without ramdisk modifications. The new DSB updates have broken the functionality of this driver, and while I made attempts to rewrite the driver I have been unsuccessful (as of yet) in reliably setting SchedTune Boost values from the kernel. I will be revisiting this in the future, but this is all to say that DSB is currently disabled by default and must be configured manually if desired.

One thing in particular that I'd like to point out in regard to SchedTune Boost tunables which I think is most relevant: The value @ root/dev/stune/top-app/schedtune.boost defaults to 10, I've found that what this effectively does is cap the perf cluster minimum frequency at 345 MHz while the display is on and only allows scaling down to 300 MHz during idle. While this is not necessarily a bad thing, you can prevent this behavior by setting top-app/schedtune.boost to a value between 1-5 which will allow the big cores to scale down to 300 MHz at all times.

With all that being said, you never have and never will be required to tune anything in order to achieve optimal performance from this kernel. You can completely disregard everything that I just said and rest assured that everything will be just peachy. By all means, I encourage you to flash and forget, I'm simply providing information for users who may be interested in some of the more advanced functionality that Neutrino offers.
[Essential Phone ROMs, Kernels, Recoveries, & Other] kakabobo:
exkm showing zram stuck in stopping state.

anyone facing this issue ?
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
It does seem as though you're right, I probably would've never noticed that. I haven't intentionally done anything that should have anything to do with ZRAM, but that's not to say it's impossible for some butterfly effect scenario to be occurring. I've found the following log entries referencing this (see attachment), and it seems to read not so much as though there is in an issue with ZRAM itself but with EXKM being unable to read the sysfs node. I'll have to see whether or not this happens with other kernel management apps.
[Essential Phone ROMs, Kernels, Recoveries, & Other] aamadorj:
It also happens with EXKM at my PH-1 running AOSiP and latest Neutrino kernel. But fornax is running great even with this issue. For me, this new build is superb! Thanks a lot, [MENTION=6474612]return.of.octobot[/MENTION].
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Yeah, I'm a bit puzzled with that one. I'm going to try and look into what's causing it and make sure it's not just an issue on EXKM's end. I don't really think it's *that* big of a deal, and I don't think there's anything actually wrong with ZRAM, I just think EXKM is failing to read it's current state.
[Essential Phone ROMs, Kernels, Recoveries, & Other] NikoZBK:
Thanks for the update. By the way, you can flash the kernel directly on your phone using ex kernel manager, works perfectly. Just uninstall ex kernel manager before rebooting and reinstall after booting
[Essential Phone ROMs, Kernels, Recoveries, & Other] galakanokis:
Thanks for the tip but curious why would you have to uninstall EX kernel manager before the reboot? What happens if you don't?

I used the command line in terminal, easy enough.
[Essential Phone ROMs, Kernels, Recoveries, & Other] NikoZBK:
I mean you don't have to, just following [MENTION=6474612]return.of.octobot[/MENTION]'s recommendation:
[Essential Phone ROMs, Kernels, Recoveries, & Other] galakanokis:
Completely missed that. I usually wipe the settings if I am changing kernels or there are big updates.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Yeah doing that my very well be sufficient. I only mentioned it because for example, the first build I flashed after I started working on the boosting updates still had an older boost duration value set and I couldn't figure out why. It turns out it was because EXKM had saved preferences setting that boost duration on boot and it wouldn't change to the new default duration until I reset the app.
[Essential Phone ROMs, Kernels, Recoveries, & Other] RandomPooka:
What's the practical effect of the ZRam doing that? Is this an issue that warrants waiting for a new build before updating my kernel/boot.img ?
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Practically, I'm not sure that there's any effect at all. I don't know why these apps are suddenly unable to interpret ZRAM's status, but I still don't believe there's actually any issue with ZRAM itself. The following commands to disable/enable ZRAM are still responsive:

su
swapoff /dev/block/zram0

(takes a minute to turn off while Android is running)

su
swapon /dev/block/zram0

So, given that it's enabled by default I guess the practical effect would be that you can't disable ZRAM from EXKM at the moment. I'm at a loss for why this is, the only new commits I've made that had anything to do with memory we're relative to LMK. I'll try reverting them to see if it has any impact, but it seems unlikely. Regardless, this is about as minor as it gets as far as bugs go and is not going to have any noticeable impact on anything unless you wanted to disable ZRAM, in which case you'd have to do it on the command line instead of through an app.
[Essential Phone ROMs, Kernels, Recoveries, & Other] RandomPooka:
Thank you. I'll probably flash it when I get home
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Yeah, I'll figure out what caused this before the next release if at all possible but I wouldn't let it deter you from flashing, this is a really minor thing.
[Essential Phone ROMs, Kernels, Recoveries, & Other] basdriver62:
Using Mtweaks worked for me ?
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Good call, I tried installing the app just to see what it would do and it does actually confirm that ZRAM swap is functioning properly. So, like I suspected this is not an issue with ZRAM itself, but rather a detection error. I'll still look into this, but it's good to know that nothing of significance is malfunctioning.
[Essential Phone ROMs, Kernels, Recoveries, & Other] basdriver62:
Thanks, I just use it for the extra virtual memory tunables in order to sync it up with the defaults of AGNi on my Kenzo. It's not that your defaults are bad, I just really like Parvinder's work and how dedicated he (or at least was) to it.
[Essential Phone ROMs, Kernels, Recoveries, & Other] JoshuaUB78:
Why is it that Wi-Fi won't work with stock Rom (rooted stock with Magisk, no modules)
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Oh yeah, no offense taken by any means. The default virtual memory settings on this kernel are just that, default. I haven't done anything in the way of tuning them myself beyond the standard CAF settings only because I usually focus on a limited range of features for each update and I haven't worked my way down the priority list far enough to worry much about virtual memory. I'd be interested to see the settings you're using.
[Essential Phone ROMs, Kernels, Recoveries, & Other] return.of.octobot:
Because the stock ROM's WLAN drivers are compiled as modules whereas Lineage's WLAN stack is built into the kernel. There are workarounds for this, but getting it to work on stock would break WiFi on Lineage. Because this kernel is intended for LOS-based ROMs, that's what I'm catering to.

I am aware that's essentially the only issue preventing this kernel from being used on stock P (that and I'm not sure how well the stock ROM is equipped to handle EAS), but the other thing to keep in mind is that when you flash these boot images on a stock build you're also replacing the OEM ramdisk and recovery with Lineage's. This is not ideal (although not inherently harmful).

Don't get me wrong, I've been heavily considering a stock variant as I would very much like to switch back to stock P myself. It's just that if I decided to go that route I'd need to totally overhaul the format we've been using and move to AnyKernel zips, which would reintroduce the TWRP dependency. I've been trying to modularize my branches in a way that would make a transition to stock as painless as possible, but that's more of an insurance policy than a guarantee that I'm going to pursue this.
[Essential Phone ROMs, Kernels, Recoveries, & Other] thirtythr33:
[MENTION=6474612]return.of.octobot[/MENTION] just wanted to say thanks for the work you are putting into this kernel. have been running the fornax variant for a couple days and am very happy with stability. I have two questions for you:

1) would you say your kernel is geared more for stability/optimization that it is pure performance?

2) how would you suggest I increase a base Linpack score (Mflop/s)?

the reason I ask is simply because I was testing out your kernel (base settings) vs other kernels (including my own) in a Linpack test. (I am something of a performance junky; OC'd i7 5960x, OC'd Corsair Vengeance LPX's, OC'd GTX 980's in SLI) lol
[Essential Phone ROMs, Kernels, Recoveries, & Other] basdriver62:
A little off topic sidenote, but I really like your kernel because it allows me to patch it for use with Magisk and I haven't found any other kernels for this phone that allow me to do that, and here are the screenies:
[Essential Phone ROMs, Kernels, Recoveries, & Other] thirtythr33:
yeah I second that!
[Essential Phone ROMs, Kernels, Recoveries, & Other] rignfool:
I don't know if it would completely require TWRP dependence...

Magisk can modify the ramdisk/zimage of a kernel while system is booted... And dd works while system is booted...

We'd just need a way to run anykernel with system booted... Which can't be that tough to do?
[Essential Phone ROMs, Kernels, Recoveries, & Other] JoshuaUB78:
I did flash the kernel even knowing it would not have working wifi, so I know how freaking fast and fluid it is! Would totally rock it with rooted stock if it were an option.