yashsingh1/xdaforums huggingface dataset:
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] DR3W5K1:
Test 3 is yielding me awesome results. I haven't experienced the wake up but yet. Wish you had it cooked with Feb update for now I'm sticking with January. I'll come back with an update on the same and comas
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
yeah, the test 3 build is much closer to what i'be been running on my device (although, i'm running the stable build right now).... i'm going to try and get an updated test build out, once I get the wake bug issue resolved...

lots of people didn't experience the bug - but it's there, I've been able to manualy manually trigger it (although, it still takes time to happen).... but I have a good idea on how to fix it...

anyway, the test 3 build contains part of the Feb 5th updates, so I don't think you are missing anything that's super critical... but like I said; I am going to try and get a more substantial update out sooner than later... January was a busy month for me, I should have a bit more time to work on things this montjh. ?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Yeah I was just throwing it out there. If this new test kernel boots I'd reckon that there aren't any kernel differences. Most likely different configuration files and possibly modems.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
NOTE: there are kernel differences in the new test build. I've changed a couple of things and reverted a commit. So if it boots - it's due to kernel changes (minor, but still could be critical).
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Sorry I meant differences between opr3 and opr1

---------- Post added at 09:18 PM ---------- Previous post was at 09:18 PM ----------

I'm basically mentally ill until I get my coffee ?☕
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
I know the feeling. lol. (on coffee)

kernel differences - no.

vendor images and possibly boot.img, yes. (but I don't modify the vendor.img)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Ok so it booted up lightning fast. So far so good. No lag during the warm up either. I'll charge her up and start testing.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Cool. I know what the problem was. not only has It's been taken care of, *but a note has been added to the reverted commit. ~ that won't be cropping back in / nail in the coffin.

thanks for dogfooding the test build and helping fix that issue ~ it's especially helpful - since I don't have an XL in front of me. So I need help with this kind of thing from you guys... Obviously, I try my absolute best to not have things like this happen - but it's tricky stuff sometimes (especially bootloop issues)...

awesome. ;)

ya, give it a good test / run. Like i said on the test build post; major changes... and I'll put an updated link on the OP (that's where I'll post test builds from now on, rather than in the forum).
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
No problem man, clean flashing is easier than ever on Oreo now with auto fill. Thanks for the kernel, things were getting boring around here.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
No probz.

More interesting stuff will be coming into my kernel (I have plans, even a ton of code already tested / experiments previously done, etc... the current test build integrates a number of previous changes that I've worked on - I'm playing catch up....).... I'm just not pushing things to fast. *Stability, first*.

and just some background on me (pixel forum already knows this)... I'm very active, in terms of developing this kernel. I've only been working on it for a month and a bit, But my changes are enormous. (like hundreds and hundreds of commit differences from stock).

I have loads of linux / kernel experience; Having been using Linux for over a decade (I don't run Mac/Win at all). I maintained linux kernel and nvidia packages for a popular Linux distribution for a few years, among other software that I've worked on, packaged or contributed to over the years....

No formal education / software engineering background - but some of the design choices (like my modifications to binder and some other kernel code) parallel certain modifications that I've done to the kernel and other software, in the past. So this isn't entirely unfamiliar or ground breaking to me.... but it is fun! ;)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Bryanx86:
Hi, thanks for the new kernel. It sounds really cool and well thought out. Are you still needing a Nov. marlin boot.img?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Hey thanks!

No. I don't need it ~ that was just a 'shot in the dark' wanted to have a look ~ but the booting issue on my test build has been resolved. so we are good. thanks for offering though
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Bryanx86:
https://drive.google.com/file/d/1m0KGwqbDXjY-Grz9jlvS9S6BZlS-c2ME/view?usp=sharing

Edit:just seen your response. Also I'm out of thanks but I want to say thank you for sharing your builds with us.:)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] montbazon:
Guys, you can install this kernel with flashfire without booting TWRP.

For this, I recommend supersu.

And there is the instruction.

https://xdaforums.com/pixel-xl/how-to/guide-android-8-oreo-root-stock-rooted-t3660591

See 6.2
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Thanks for pointing that out for SuperSU users. very helpful... I think some users in the Pixel forum are also using Flashfire + SuperSU.

I personally don't use SuperSU because it's closed-source and I try my best to avoid close-sourced software when/where I can... I also prefer to not modify /system ~ So I use Magisk; systemless mods (Magisk is also open source).... therefore, SuperSU gets no personal testing from me ~ although it should work fine / haven't had reports stating otherwise. Chainfire makes great stuff ~ not a knock on him - just personal preference.

I may publish normal boot.img(s) for my kernel at some point; allowing cutting TWRP out of the process too (magisk can patch boot.img(s) installed or not), but it hasn't reached the top of my list quite yet. (I'll get to it though).
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
haha. fun little update that I'm happy about (now that I can push on with testing, since the test build is booting and in the wild now)

Just added a nice improvement to the audio driver

Previously I had picked up a change from Wahoo, that would allow clients to upgrade priority for pcm playback on LOW_LATENCY_PCM_MODE (this path is what any app that cares about making sure it's buffers/playback arrive on time will use... system sounds, etc don't use this path ~ proaudio apps do. Possibly apps like Duo / Voip might too, idk yet).....

However, one thing that I didn't underand (midly baffling actually); Why didn't Google Kernel Devs or Qualcomm implement this for pcm capture (recording)...wtf??? => There are definitely apps that would prefer to have less of a delay on capture....

So I decided to implement it myself; it's incredibly simple to do (it's literally copying/reusing a few functions, definitions, etc... pasting them and changing a few bits so that the functions are to be used for TX (transmit) instead of RX (recieve) - and then injecting the calls into the msm_pcm_capture* functions....

Turns out; it works really well! ... For my test case - I installed an app called LoopStation. This app requires that you calibrate it, so that any delay in recording; will still be synchronized on playback with the metronome.... * before applying my changes; there was a delay and I would need to align the waveform to the metronome.... * But after making the necessary changes; I wouldn't even need to calibrate the app at all ~ It's nice and synchronized all on it's own....

This could benefit a variety of apps ~ but I'll need to find more examples. It shouldn't break anything either - as it only affects apps seeking low latency on record.... I'll give it a good round of testing before adding it to any build, for sure.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Sounds good, I'll test audio with my hbs-1100 platinums. Honestly some of the most underrated BT headphones.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Well, the above isn't in the test build. * it will be in the next test or RC (release candidate) build

That said - I would love to see some bluetooth testing happen ~ I don't own bluetooh speakers or headphones - so I haven't tested that kind of stuff (although, my kernel does contain 2 commits pertaining to bluetooth), so it would be good to know how that's working...
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ChongoDroid:
Aptx-HD is awesome. I don't even get to appreciate most of the benefits since none of the music I listen to is HiFi.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Lol. I had to google that - no idea what you were talking about! haha.

so your bluetooth headphones are working well with the kernel? ~ I ask because I pulled in a patch that is supposed to improve scheduling of bluetooth transmissions (by giving it a higher priority). which in theory would result in lesss of a change of any drop offs / underruns... ~ so I was curious about that (but if you notice no difference - that is also a good sign. lol)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] almightysiman:
I can confirm the bluetooth is working great with my Bluetooth speaker.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Cool. No reason it wouldn't. but good to know.

I would be interested at some point, if you happen to notice any situation where there was an improvement; an example would be if there was a situation where it would drop out, but now doesn't or something like that....

The important thing though - is that it's all working, no regressions. Knowing if there was some even marginal measurable improvement would just be frosting. lol

thanks man!
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] natri23:
You should change the description. It says Jan patch
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
Thanks, updated... I did that on the sailfish thread, but forgot to on the marlin thread (it was late lastnight, when I updated the build / info... and I was pretty tired, after messing around with the i2c-msm code ;))
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] kingbri:
I am running the new stable release, working well with firehound
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
glad to hear it.

I like those guys logo for their rom. actually, the rom looks pretty good in general - had a read through their thread, yesterday. ;)

Question: How is the LED stuff working with their rom / my kernel?

I ask because if something isn't working quite right => our led driver is actually missing some bits, that I've noticed in other msm8996 kernel trees ~ I could probably update / add in missing stuff ~ the LED stuff is pretty isolated and it would be pretty easy to update the driver, imo.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] kingbri:
I don't like the led as much, but it stays lit on your kernel, is that what you want?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
I don't know what you mean by stays lit?

I was more curious, just if when you tweak any of the LED controls that they work, as expected....

no worries though. If it isn't a feature that you use, no big deal... If someone using it, notices something odd ball, i'm sure i'll hear about it. (and when I had tested LED with some of the custom LED control apps - it seemed to work as expected...)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] -iNSiGhT-:
Just flashed your Feb build.

But had to remove lockscreen (fingerprint) to be able to flash through TWRP 3.2.1-0.... Even USB OTG didn't work (remember i used it, maybe with an older build of TWRP).
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
yup. it's a bit of a hassle. gotta wait until twrp is fixed, unfortunately...
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] -iNSiGhT-:
I just can't wait to flash your kernel... :D
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
lol. I thought u just did? ?

or do you mean the next update? if so;

i'm working on it. still sorting out the I2c bug. kinda just waiting to verify it's gone....

and in the meantime, I've started pulling in a bunch of stuff from my local branch into the stable branch. FS, VM, sched/locking/futex rework (plus some potentially good optimizations), block, tracing (rework), arm64 (fixes), etc... and some more one-off commits, optimizations, some bug fixes too...

so assuming, I can get it ironed out. I should be able to get a bigger update out soonish...
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] -iNSiGhT-:
I did...

Was just mentioning I can't wait to flash even though I've to reset fingerprint.

As always, your life first. We just wait patiently with our Pixels already running your stuff. ;)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] montbazon:
Updated today. Works perfect as usual.

If there is something to notice, I will write again.

Thanks for supporting.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
no probz. and thanks!

yeah, everything should be good. only issue i'm aware of is the I2c / DT2w / touchscreem bug that I mentioned... I've half-solved the issue on my end... so far, I've fixed the issues in I2c-msm-core itself, but now I have to fix the synaptics_dsx touch driver (touchscreen).

I was looking at a newer version of the synaptics dsx driver lastnight, that appears to have what I need to fix the IRQ handling (after that only small fixups will be needed)... so i'm going to see if I can pull those changes in later. hopefully, it isn't to painful to fix. we'll see! ?

my local build (with all of the updates/reworks) is running very well too. haven't have any issues, at all - or rather any that I haven't already fixed ?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Nick80835:
Hai, I'm making an attempt at building your kernel inline with my ROM and I'm hitting some issues, I can show you the exact errors later. :silly:
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
sure. pm me...

I would expect that you'd hit problems, especially with an older toolchain... what versionof GCC are you using?

you're probably going to have to build my kernel with GCC 8 or linaro 7.x... you should be able to specify when building your ROM to use a different compiler for the kernel...

also, make sure you use the v2.6 branch, as that would be the current stable... I haven't published my current local branch yet. will do, soon though.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Nick80835:
Okie, will do, and I'm using GCC 4.9.4 still (the default toolchain) but I should probably change toolchains, yeah. Also, it's not an error with the kernel building itself, it's about the redefinition of something that's defined in both the kernel and ROM.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
hey nick... OK. well, I'll have to see the error to have a better idea of what is happening, then we'll see if we can't resolve it ? ...

and yeah, id suggest using a newer toolchain (just for the kernel) because I don't test against old toolchains, i

be made changes to make GCC 6+ happy ( beyong just setting flags to shut up warnings, like some people do)...so no idea how old GCC versions work it...

anyhoo, yeah. just pm me later and we'll try n sort it out.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
just a wee update on progress... i'm still working on fixing the one issue that i mentioned before; DT2w related (sort of, not really)... I also believe that the sleep / screen off bug that was in my test builds is NOT present in my current local build...

I'm doing a lot of stress testing && have actually fixed a few splats that I wouldn't have hit, had I not been using hackbench and a few other utilities...

there should be some good improvements that come out of this effort. i'm already seeing improvements to SMP performance... just for kicks;

sometimes the single-threaded performance is closer to 1900/2000 - just not on this particular build or run...
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] muppetmaster916:
The hype for the latest build is strong lol. Will it include the feature that turns pixels into sex dolls? Lol

On a serious note thanks for keeping us posted and running a kick ass kernel.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] almightysiman:
The result is promising,cant wait to taste the final build.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] muppetmaster916:
[MENTION=7810360]nine7nine[/MENTION] how's it coming along? You're uncharacteristically quiet lol.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
oh, I've been working on stuff, I kind of covered it in the other thread earlier (when asked), so I'll just quote myself;

the first issue I mentioned about devfreq I have fixed, but I still have a couple of things to fix up still...
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] muppetmaster916:
An awesomely detailed progress update as usual, thank you.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] ayylmaomyman:
Good luck fam
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
no probz. I wish I could have already pushed an update for the kernel that I use right now, because for the most part; it is stable for day to day use (as in, it's what iu use. lol) - but I really would like to resolve the few spots where is can cause issues before pushing it ~ that way I don't have to deal with user issues, for stuff I'm well aware of (it gets a bit stressful, when things break or cause issues for people, for me)...

but once the kinks are ironed out, it'll be a nice upgrade over the current stable build.

A couple of other interesting things to note: Regarding battery life; I think I'm seeing an improvement. I've had around 7hrs of SOT on both cycles ~ which isn't atypical, however as part of testing my cpu for instabilities, on top of running the kernel test module (sultanxda's) and running hackbench, etc - my running kernel is also overclocked (which makes it consume more energy). So I would expect that at stock speeds, I would likely be getting more SOT than I have on each cycle (by how much, who knows).

Thanks, sorted out another splat lastnight. This morning, I'm doing some general fixups, later on. I think I'm going to dive into the scheduler code, see if I can't rework and update it against my 4.9-eas kernel. (I'm sharing a lot of code between my 3.18, 4.4 and 4.9 kernels). That should take care of a few more minor annoyances....

then I'll see where things are at, after that.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] kingbri:
[MENTION=7810360]nine7nine[/MENTION], 7 hrs!!!
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Crazycat362:
Sounds extremely close at this point?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] kingbri:
[MENTION=7810360]nine7nine[/MENTION], I have a question, if you include more governors in a kernel, would it upset the balance that you're trying to achieve right now?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] :
I'm not sure what you mean by "balance", but TBH I have no interest in adding other (cpufreq) governors into my kernel. I've tested or used the majority of downstream android governors and most, while not necessarily bad or anything - are unnecessary, from my perspective.... *** I would need compelling statistics that demonstrate real value ***.... but even then; they fall out of the scope of my goals.

Schedutil covers nearly all workloads + tends to have the best energy efficiency (regardless of workload).... and there are really only a few corner-cases/scenarios, where it may not fit/address perfectly. ===> Those being; legacy apps that don't support android's "sustained performance mode" (but realistically should) / apps that are sensitive to cpu frequency scaling AND a few other scenarios where one might want to peak out performance ~~~> But switching to performance mode && using the performance cpufreq governor is what would be desired there anyway..... Lastly, given that one of my goals is continuing to support upstream/android EAS development - it makes zero sense to care about any cpu governor; other than Schedutil...

I'm more interested in reworking the kernel core to support features that I'm after, being able to use more 'state or the art code' from newer kernels, improving certain workloads, improving multi-threaded performance, etc, etc.... All stuff that adding in XYZ governor will never fix or address.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] DR3W5K1:
OT but I think it's okay. Sorry if it's not.

I haven't flashed system with TWRP since nougat. Would anyone be willing to recommend? I was thinking about flashing RR.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Herk718:
SCREEN ON TIME WITH THIS KERNEL IS UNREAL Thx! [MENTION=7810360]nine7nine[/MENTION]
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] anderson79:
what app do you recommend for kernel configuration?
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] bkkzak:
It's at the bottom of the OP.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] kingbri:
If you want a free option, try kernel auditor
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] muppetmaster916:
[MENTION=7810360]nine7nine[/MENTION] recommends running it in the state it's flashed in anyhow. So I just flash it and don't think about it again. Works awesome and I don't waste a bunch of time placebo tweaking like I used to.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] anderson79:
that's just what flashes and I'm doing great in deep sleep does not consume me at all, I was much better but as I play a lot the battery does not last so long but otherwise it would be much better thanks [MENTION=7810360]nine7nine[/MENTION]
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Dachfenster:
I don't know what it has to do with the kernel but I didn't get it to work either. Tried the Magisk thingy, yet no luck.

I've tried it with an AOSP and a LOS ROM. As soon as I installed your kernel, the root directory wasn't visible through Solid Explorer. Back to the ROM's stock kernel or ElementalX it was visible again.

Of course it's the app's fault because like others have pointed out, other file managers work.

Although it's off topic, I've attached a Logcat. Just wanted to share my two cents regarding this topic. No need to have a look at it.

Keep up the good and informative work. :)
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Donric13:
It's the app. I also got no files in root directory with solid. Try root explorer. Works perfect in root directory. All other things work fine with solid explorer.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Dachfenster:
As I've said it's the app... but in combination with the kernel.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Donric13:
In other rom i can see root directory with solid remember (long time ago i had a rom not with this kernel). But i also remarked in oreo with solid i wasn't able to delete apps in system. With root explorer no problem. So i think solid has a problem with oreo.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] MArtyChubbs:
Great work! This is the first kernel that significantly saved my battery life. SOT went from 2:01 to 3:03. That is good for how I use my phone.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] bkkzak:
Solid Explorer worked fine for me on previous releases of the kernel, but it isn't working on this most recent release of the kernel
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] Dachfenster:
Interesting. Haven't tried previous iterations.
[Google Pixel XL ROMs, Kernels, Recoveries, & Other] kingbri:
[MENTION=7810360]nine7nine[/MENTION], how's the development going? Still any issues?