yashsingh1/xdaforums huggingface dataset:
[Google Pixel 6 Pro] boxemall:
Regarding the different kernels:

is the version number on kernels the same? i ask since the A12L is "still" on 1.8.x while the other kernel is 2.x.x,...

i assume that if versioning (minus the differences between A12 and A12L) is the same, there is no up to date security patch on the "older" A12L kernel? this is the only kernel that works with protonAOSP since they changed to A12L Base. this is kinda important as the latest secpatch (april) is said to fix over 40 issues.

The A12L kernel seems to have passthrough charging enabled, at least that`s what ACC tells me and the battery behaviour seems to fit that assumption. How comes it is present/working on that 1.8.x kernel? i might have overlooked it but i don`t remember passthrough working on the A12 kernel or am i wrong? maybe it was added and i didn`t realize.

other than that i can`t say i have any issues with that kernel.
[Google Pixel 6 Pro] RetroTech07:
Is it possible to add an option in the kernel settings to adjust the haptics / vibration to be stronger than what Google recently changed in their April patch, or does it not work that way?
[Google Pixel 6 Pro] prokiller1199:
Unfortunately, it is happening for me as well. I have 2 picky or should I say troublesome bank apps is detected with root. Once I return to stock kernel, they will work like magic, this doesn't happens on last month patches with kiri kernel. Maybe one day i will come back to this kernel Thanks.
[Google Pixel 6 Pro] Texan1:
It is possible, Despair kernel has incorporated stronger haptics/vibrations which is very useful (no option to tune these, simply made them much stronger as default)
[Google Pixel 6 Pro] Freak07:
It's already included and accessible via CleanSlate config app from the beginning of this kernel.

It was adjusted to accommodate for the lower vibration intensity that was introduced with the march update already as mentioned on the most recent release post.

Strength of the vibration can be tuned as well.

Check the attached screenshot.

Tell me the apps, take proper logs to look at while root is detected and maybe it will shed some light on this.

Feel free to post issues about root detection in the magisk forum section or seek help there as well. They'd appreciate logs there as well.

Check the few last pages. One user says my kernel breaks a specific app while others have the same issue on stock kernel as well, while it works for others on stock.

As i stated previously the kernel has no relation to this. Maybe there's a new method out there that targets custom kernels, but it doesn't make much sense. Not many device out there running 5.10 kernels, and detecting root/unlock is far more effective.

Either way I understand the frustration, but there's not much I can do about it.

April source didn't add anything new.

The kernel for stable has basically all parts from A12L included (that's why I'd assume ACC might behave the same for you on both releases) except the changes for the touch driver as they depend on firmware as well.

That's basically the only thing that stops the builds from being unified.

I didn't find any time to compile a new A12L kernel yet. I barely struggled to get out the stable update this week.
[Google Pixel 6 Pro] RetroTech07:
My Apologies and thanks to those giving info about the vibration/haptics boost. I'm still new to flashing different kernels and I SWEAR I read the release notes, but missed that one vital part which is why I asked!

Thanks again!
[Google Pixel 6 Pro] vassosman:
About time Google

https://twitter.com/i/web/status/1512136326967021581
[Google Pixel 6 Pro] Jiggs82:
@Freak07 you're really a beast man kudos for the find 🙌🏻🔥👌🏻
[Google Pixel 6 Pro] Freak07:
A12L QPR Beta Kernel

For those on the A12L QPR Beta here are zips to try, since there were a few requests now, but unfortunately I didn´t have time.

They should work fine on QPR Beta 2 as source was pushed already.

That kernel has feature parity with the 2.1.0 release. There were no changes to the kernel we didn´t already have, except the touchscreen drivers that are not compatible between A12L stable and A12L QPR Beta, hence the need for adjusted builds.

I don´t know what´s the current situation with magisk and flashing kernels on QPR Beta, but it´s probably best to use magisk stable if you don´t want to face issues.

I´m not myself on QPR Beta so please leave feedback, but remember:

These zips are provided as is.

Feel free to report issues with proper bug reports (containing logs, steps to reproduce according to the guide linked in the FAQ), but they might remain unresolved if it´s not easy to fix without running A12L Beta on my own end.
[Google Pixel 6 Pro] GrandMstrBud:
I'm curious as well
[Google Pixel 6 Pro] bush911:
I feel too bored so I flashed the latest 2.1.0 on my Pixel 6 and found the phone is not smooth as previous 2.0.1,

then after a half day use I flashed back to stock kener, then back to 2.1.0

at the moment I am writing this post, I flashed back to stock again:ROFLMAO:

overall, 2.1.0 is better for battery, but I can still feel the sense of difference when using tasker to unfreeze and launch the same app.
[Google Pixel 6 Pro] bjevers:
I flashed back to 2.0.1. For some reason 2.1.0 is laggy and unresponsive at times on my P6Pro. Maybe something with the powerhal changes?
[Google Pixel 6 Pro] IvanPTachev:
I guess I can confirm that on QPR beta 2, using the canary magisk gave me the device corrupt message when flashing the kernel.
[Google Pixel 6 Pro] Freak07:
smoothness and app launching times are different things.

I checked both on my end and there´s definitely no regression on my end towards 2.0.1.

App launching times are improved very slightly on my end for most apps, as for measuring how long the the main activity takes to spawn.

Tracing also shows no regression for smoothness or missed frames.

Check if something is running in background maybe.

If you roll back to stock or a previous version of this kernel there´s always a reboot involved, which might clear other problems out.

Can you reproduce them somehow or narrow it down when the issue your describing happens? If yes, it would be great if you could take logs when the lags happen and also do some tracing for me.

There´s no such issue on my end and I used the phone the past weeks pretty heavily so I´m not able to reproduce the issue to try to debug it.

If you have some time at hand PM me and I´ll tell you how taking a trace works.

No idea to be fair. It might be possible, but I really don´t want to introduce that kind of instability to the kernel here.

Slight undervolting might run fine on one device but might crash other devices immediately or introduces random issues which will produce bugs that are not debuggable.

Thanks for the report. But were you able to boot the flashed kernel when pressing the corruption message away or did you get straight back to bootloader?

GitHub - nermur/no-tethering-restrictions: Unlimit/un-throttle/un-restrict/bypass the 'tethering/hotspot' classification for Android

Unlimit/un-throttle/un-restrict/bypass the 'tethering/hotspot' classification for Android - GitHub - nermur/no-tethering-restrictions: Unlimit/un-throttle/un-restrict/bypass the 'tether...

github.com

maybe this is helpful. kernel support for this is enabled when running this kernel.
[Google Pixel 6 Pro] Utini:
Ye I fully agree with not having undervolt values implemented in the kernel.

But I believe the kernel needs to support undervolting to even be able to do it?

And then one would probably find an app that can set the values, run benchmarks and figure out what is save.
[Google Pixel 6 Pro] IvanPTachev:
Forgot to add - no it didnt boot. It went to the Google logo, but never actually did the little spin animation and just sat like that for a couple of minutes. Had to turn it off by holding the power button for 20 sec. I am now flashing it back to stock with the Android flash tool. None of the fastboot or Ota flashes did get rid of the message. I guess I'm missing something.
[Google Pixel 6 Pro] Freak07:
alright thanks. seems magisk stable it is for beta at the moment.

to get rid of the corrupt message flash a boot.img from an older firmware package. seems counter intuitive but it´s confirmed working. check the FAQ in one of the first posts on the exact steps.

google fixed a verity related issues with the stable march firmware, which dropped early last month and I´m not sure if that´ in the beta as well. regardless some users unfortunately still run into this issue when flashing kernels, updating or rooting their phones.

At least there´s a workaround that doesn´t require wiping regarding the verity issue now.

To restore stock kernel after flashing this kernel.zip simply restore the images from factory images as detailed in the FAQ as well. :)
[Google Pixel 6 Pro] IvanPTachev:
Thanks for the info. Tbh, I should have been a bit more thoughtful, as I thought I had installed the stable Magisk, but forgot I had the canary from the previous time I got the kernel and realized that just after I got the issue. I guess doing stuff at 6am isnt my thing :D
[Google Pixel 6 Pro] GrandMstrBud:
Thanks, I read it a few times and it's confusing to me. I'll read it again a few more times maybe I can make sense of it
[Google Pixel 6 Pro] Admiral2145:
Same on my p6... It's sluggish when waking up.
[Google Pixel 6 Pro] Psfanboy88:
+1
[Google Pixel 6 Pro] Lughnasadh:
Just to be clear, was it Canary 24305 you were using or the latest that was just released, 24306?
[Google Pixel 6 Pro] Lughnasadh:
FYI: The latest Canary, 24306 (which fixed bootloops & corrupt messages when updating to the April build via "Install to Inactive Slot" on the Pixel 6 series, even when using Stable Magisk, among other things), is working fine for me on the 12.1 April Stable build using Kiri 2.1.0.
[Google Pixel 6 Pro] spr33:
I think the issue is more around the beta IIRC.
[Google Pixel 6 Pro] Lughnasadh:
Yes, but I was just reporting that it works on the April Stable 12.1 build with the latest version of this kernel in case anyone wants to update to that Canary version 👍
[Google Pixel 6 Pro] IvanPTachev:
You are indeed correct that I used the 24305 canary one. I guess that might have solved it. Thanks
[Google Pixel 6 Pro] Nekromantik:
people should just stick to stable and no beta lol

life much easier then
[Google Pixel 6 Pro] Lughnasadh:
I'm not sure if using 24306 with the QPR3 Beta 2 build and this kernel will give a different result, though. 24306 fixed an issue where people were getting bootloops and the corrupted message when updating to the April build via the "Install to Inactive Slot" method on the Pixel 6 series, among other things. There were no "intended" fixes in 24306 to make it work with kernels on QPR3 Beta 2.

So it may or may not work with this kernel. I'm thinking not, but who knows...
[Google Pixel 6 Pro] Lughnasadh:
🎵 "But Mama, that's where the fun is"... 🎵 🙃
[Google Pixel 6 Pro] boxemall:
I know this is not rom related but wanted to drop it real quick. A12L 1.8.9 worked like a charm on latest ProtonAOSP 12.3.0 (with root as well) while the latest 2.1.0 QPR takes ages to boot. after boot many things did not work (like tap to wake screen, calling neither since there was no sound).

I haven`t tried it all but went back to stock Protonkernel which sadly has no passthrough charging.

i can only hope proton will soon be qpr compatible.
[Google Pixel 6 Pro] GrandMstrBud:
Is there an easier way of accomplishing this? I'm far from a developer and reading that confused me and gave me a headache,😂
[Google Pixel 6 Pro] capntrips:
I was considering making a simple open source app to handle flashing this kernel from the zip file, but I have a quick question about the vendor_dlkm partition. I see early in this thread that no one had figured out how to flash it on a running system, but with the 1.4.0 release, it was noted that dd can do it, but that might not be the proper way to handle it.

Was a proper way ever discovered? Unless I'm missing something, the block device is actually smaller than the vendor_dlkm.img file in the factory image zip. I saw on another post that it isn't recommended to return to stock using apps, is that why?

I wonder if a static version of the fastbootd binary could be built to handle it; otherwise, liblp appears to already be on the device, so maybe the fastbootd methods could be unwrapped enough to avoid completely reinventing the wheel.

Thanks in advance for any thoughts on topic, and sorry if this isn't the appropriate place to discuss it.
[Google Pixel 6 Pro] Logix:
i dunno what i did wrong did 1.8 latest ota and stable magisk flashed via fkm and ex and still bootloop
[Google Pixel 6 Pro] Lughnasadh:
Do you mean you flashed Kiri version 1.8 (1.8.4?) on the April build? I think that version is meant for the February build. 2.1.0 is meant for the April build.
[Google Pixel 6 Pro] Logix:
ah got it i must have misread! will try that now thank you kindly
[Google Pixel 6 Pro] Nezorflame:
Can confirm that 2.1.0 for 12L works on beta 2 for Oriole, using Magisk 24300 (flashed with EXKM).

Thanks @Freak07 for your outstanding work!
[Google Pixel 6 Pro] arvylas:
For me both smoothness and app launching was worse. A few ms in app launching isn't much of a deal but I had lags here and there and frame skipping. There's also a multiplayer game I play occasionally which was stuttering at times, especially with the charger connected or when the device happened to be warm. Also tried several reboots.

I'm back on 2.0.1 which is perfect and nothing of those things happen.

I have a P6 btw not a pro.
[Google Pixel 6 Pro] Israafil:
So i installed the kernel and immediately noted some odity regarding the cpu scheduler. Block 1 seems to be locked at 1197 mhz, block two can use max freq and block 3 seems to jump and lock most of the time to 1426 or 1745. It seems to me the powerhal tweek in this version favors battery over performance.
[Google Pixel 6 Pro] Lughnasadh:
Are you using FKM to see frequencies? If so, that seems to be off. Try EXKM. DevCheck may be off some too. EXKM seems to be the most reliable.
[Google Pixel 6 Pro] Israafil:
I am using exkm, manualy changing max freq for block 1 dont work, its stuck at 1196, block 2 works fine, block 3 jumps around need to observe and report later but no matter what i tried block 1 always stays either on 1098 or 1197.
[Google Pixel 6 Pro] Lughnasadh:
Hmm, EXKM is showing normal frequencies for my little cores, from 300-1803. The Prime and Performance cores are normal as well.
[Google Pixel 6 Pro] Freak07:
As far as I´m aware those values sit in the kernel device tree, which is handled and generated at compile time. There´s no way to edit this during runtime.

do you all have regular pixel 6, non pro devices?

If so I´d appreciate logs. Open a few apps, play around with the phone and send me a logcat and a dmesg. you can take those easily via exkm/tools/save logs.

Thanks for confirming @Nezorflame and you´re very welcome. :)

You´re not supposed to change the max freqs via exkm manually. The powerhal/thermalhal sets those limits dynamically. If you change them the hals will change those values either immediately or once a event is parsed where they set it.

I haven´t changed anything regarding limiting maxfreqs at all in the recent releases in the powerhal. Google tightened thermals quite a bit since the p6pro released. If the phone is warm it will throttle. I also noticed, as we´re getting to spring season here and the sun came out more than during winter, the phone will fall back to 60fps quite quickly when it gets warm in direct sunlight.

Google doesn´t allow the phone to get as warm as other brands before throttling kicks in I noticed.

If I let my phone just sit at the "frequency monitor" in EXKM it´ll basically sit most of the time on 300/400/500mhz (little/mid/big cores).

FKM CPU monitor seems to be a more expensive operation and puts more load on the scheduler. There the little cores hover around 1401mhz, while the others idle at lowest mostly if I don´t touch the phones for longer.

Generally all monitor apps can be deceiving that way.

If yours stays maxed out 100% of the time there might be an issue with an app being stuck in the background.

Do you use a regular Pixel 6 or a Pixel 6 pro?
[Google Pixel 6 Pro] Freak07:
attached are two zips for you to try on proton rom.
[Google Pixel 6 Pro] Psfanboy88:
Thanks for the response. I have a pixel 6 Pro. Closing apps for example stutters.
[Google Pixel 6 Pro] Freak07:
I´m sure a lot of people would welcome an open source method for this!

At the moment vendor_dlkm is simply dd´ed to its place when flashing via a kernel manager instead of resizing and properly being flashed to vendor_dlkm which is part of super, which is dynamic partition.

A check is built into the ak3.zip so a vendor_dlkm.img image that´s bigger than the actual current partition size will abort anyway.

However I ran several times into an issue, where after flashing a much smaller vendor_dlkm image via a kernel.zip in exkm/fkm (which has an unused wifi driver disabled, which cuts the image by a bit more than 10mb), then afterwards flashing a kernel.zip with the bigger sized vendor_dlkm resulted in a bootloop, but after manually flashing the same larger vendor_dlkm via fastbootd the device started booting again.

That´s the reasoning behind the recommendation to restore the images via fastboot/fastbootd, especially to restore vendor_dlkm always via fastbootd.

You´re correct that having a static version of this would be the way to go forward to properly do this on a device booted to the OS.

You can check here as well:

GitHub - phhusson/vendor_lptools

Contribute to phhusson/vendor_lptools development by creating an account on GitHub.

github.com

I´m not very familial with all of this and I´d really appreciate if somebody could get proper vendor_dlkm flashing on a device booted to the OS.
[Google Pixel 6 Pro] IvanPTachev:
Did I miss some of the changelogs, or does the kernel indeed allows passthrough charging? Or is it the rom that has it?
[Google Pixel 6 Pro] acc.ayman7:
I can confirm that too.
[Google Pixel 6 Pro] Freak07:
A12L QPR beta has a lot of changes for the battery driver. Those changes are in the stable A12 build as well as the QPR build at the moment, since I merged the A12L code. I assume this is what enables the function as seemingly supported in ACC. I´m not using ACC, that´s why I mentioned "seemingly" based on the post you quoted.

I also replied regarding this here:

https://xdaforums.com/t/kernel-05-0...pixel-6-pro-aka-raviole.4358435/post-86705139

I´m also having a Pixel 6 Pro and I´m not noticing any stutters when closing apps at all and can´t reproduce this behaviour on my side. Everything is smooth.

Make sure there´s nothing wonky going on in background (check via top command in terminal/shell for example, please search the thread I explained how do to that a few times already), make sure you´re not running any mods that might cause this, don´t change any kernel settings in exkm/fkm etc.

Please check this post for a reply/answer to this:

https://xdaforums.com/t/kernel-05-0...pixel-6-pro-aka-raviole.4358435/post-86705139
[Google Pixel 6 Pro] cosy6ay:
which version works on qbr beta?
[Google Pixel 6 Pro] boxemall:
Yesterday I tried re-flashing a backup using FKM (made a backup b4 flash) but it went wrong and device was dead (device corrupt), so I had to re flash proton (update was enough so all my data was still there). In case it goes wrong again, it seems like FKM isn't able to reflash the backup I made before flashing the kernel. Not sure what's the best way...

I've done this many times, but having an FKM Kernel Backup seems to be not a good idea...
[Google Pixel 6 Pro] boxemall:
Here you go. This is a Screenshot i made inside AccA (acc GUI). Although this is the stock proton kernel (12.3.0) but i got the same message with A12L 1.8.9 kernel. I can't tell if it's ROM or kernel related but as mich as I know (or was told at least) it should be kernel stuff. Since Google is working towards longer battery life and even teamed up with ifixit it might be a new thing. All I can tell is that it worked (at least with kiri A12L 1.8.9) since it stopped right at the charge limit.
[Google Pixel 6 Pro] capntrips:
Turns out building a static version of fastbootd is easy enough, but it chokes on DM_DEV_CREATE with device or resource is busy (as does lptools). Unmounting and even removing the existing logical partition had no effect.

Edit: It turns out the issue was the partition was already mapped, and fastbootd was try to map it, again.
[Google Pixel 6 Pro] GrandMstrBud:
How do you spoof TTL? Looking for a way to natively tether without the carrier detecting hotspot usage?
[Google Pixel 6 Pro] awarman:
It seems like performance is lackluster on the 2.1.0. I noticed some lag and stutter where I didn't on 2.0.1 and I ran Geekbench to find my scores down. I couldn't hit my usual 1000/2800. I flashed 2.0.1 and let it settle to find that my score was getting back to normal. Just reflashed 2.1.0 and I'll benchmark later again to see. This is on my Pixel 6 Pro.
[Google Pixel 6 Pro] Freak07:
No FKM is not capable of restoring the device back to stock after flashing this kernel from a backup taken via FKM prior to flashing the kernel. Same goes for EXKM.

I pointed out in the FAQ in one of the first posts how to restore back to stock after flashing this kernel in the most appropriate fashion.

Essentially FKM takes just a backup of boot.img.

A few years ago everything kernel "related" was just sitting in the boot.img. Then dtbo got phased out to dtbo.img. Last year dtb got phased out to vendor_boot.img instead of sitting in the boot.img last year.

Now many kernel drivers are compiled outside the zImage as kernel modules and end up in vendor_boot.img and vendor_dlkm.img.

When flashing this kernel all 4 of those images get flashed/modified and all of them need to be restored to stock if the users wants to return back to stock. The best way to achieve this is described in the FAQ.

I suppose ACC checks some sysfs endpoints from the kernel. I wouldn´t count on this being 100% working either way. I think I remember a tester of mine also thought this would work, while it randomly reset during the device´s uptime.

Either way it´s probably handled by the charging driver. If 1.8.9 worked for you 2.1.0 should work fine as well if it boots. Try with the "new" upload from yesterday if the original 2.1.0 didn´t work for you.

Read the FAQ so you can restore back to stock proton in case something goes wrong.

No problems on my end with geekbench scores, see attached screenshot. Benchmarks are "just" benchmarks.

If something is running in background e.g. play services doing stuff, play store running or thermals are kicking in (google tightened thermals quite a bit starting with march), other apps run alongside geekbench in background you might see variations in score.

Thanks for the update and the effort! It´s really appreciated!!
[Google Pixel 6 Pro] bush911:
You use 2.1.3 which differs from we are capable of downloading 😂
[Google Pixel 6 Pro] spr33:
https://xdaforums.com/t/kernel-05-0...pro-aka-raviole.4358435/page-65#post-86707797

The search works y'know 😜
[Google Pixel 6 Pro] Texan1:
This is on stable 12.1
[Google Pixel 6 Pro] awarman:
How are you getting 2900 multicore? I've never been able to achieve that.

Looks like it's about back to normal but I'm curious how you are getting 2904. Any tips?