[10][KERNEL][06.12.2019] Kirisakura-Q 10.1.0 [3.18.140]

[Freak07]

Hey guys and girls,

So straight to Topic.

The Kirisakura-Harmony is based on the latest google sources. On top of it are the latest EAS patches directly from Linaro. It also includes a few Audio Patches from CAF. Power Gating is disabled so you can use this kernel with @chdloc ´s excellent, I am wholeheartedly recommending it, biquads mod. If you grasp what you can do with it, you will never need an equalizer in your life again. So this is also an audio oriented kernel.

As I said I am still learning. The Feature list Comes here:

- Based on the latest Sources from Google for Android Q/10
- Upstreamed to 3.18.140
- Schedutil included again
- GPU Adrenoboost
- Wake gestures from flar2
- KCAL from savoca and ported by tbalden
- HBM enabled and accessible for the user
- Backlight dimmer is added
- FIOPS, SIO and MAPLE I/O Scheduler included
- Updated BFQ I/O Scheduler
- I managed to merge some Audio Patches from CAF, which should enhance Audio
- Power Gating disabled so you can use @chdloc ´s biquad mod
- Vibration Control
- Sound Control
- sdcardfs
- Sched and latest Schedutil (with latest upstream patches is also default)
- Updated EAS Machinery
- USB fast charge

Instructions for Android P
How to flash the Kernel:

1. Download the kernel.zip to your device

1a. Optional: While it may not be necessary all times, you may want to restore stock boot.img, re-root with magisk and optionally install twrp.zip if coming from another kernel. Before reporting issues make sure you do that! Thank you!

You only need to do either 2a OR 2b
2a. Boot to TWRP and flash my kernel.zip. Root will be preserved!
or
2b. Flash kernel zip in EX Kernel Manager or FKM app. Root will be preserved!

3. After booting up make sure to set schedutil as default CPU governor (check apply on reboot option) to fully profit from the kernel´s changes!

4. Enjoy your device now!


Android 10 Download:
Download:
https://www.androidfilehost.com/?w=files&flid=300707


Download for PIE

Download:
https://www.androidfilehost.com/?w=files&flid=198589

Oreo Kernel Stuff

Download:
https://www.androidfilehost.com/?w=files&flid=152851


Changelog-Mainline:

0.1
- Initial release

0.2
-added safetynet patch

0.3
- Add GPU OC
- Update wake gestures
- Many new Performance Patches
- Updated dm verity

0.4_1
- More performance tweaks
- Made my kernel a flashable zip <-- I hope you guys are satisfied now

0.5
- add Slimbus OC <-- Increases Audio Quality
- Various crypto Patches
- More Patches that may help with Performance
- added wakelock Patches
- added a few alsa patches

0.6
- added soundcontrol
- disabled some logging stuff
- some more tweaks

0.7
-enabled few other tcp congestion algorithms <-- westwood is now default
- set default iosched to deadline as it works best with eas kernels if we trust the documentation

0.8
- added sdcardfs <-- take a look at the FAQ on how to enable it
- added in two new governors, alucardsched and darknesssched
- merged in some other commits. take a look at my github

0.9
- when deactivating kernel side dt2w and s2w, one is still able to use the stock google dt2w implementation
- code updates for both alucardsched and darknesssched <--- if anyone has time please test and report back how they work with 0.9
- added option for GPU boost <--- disabled by default, take a look at the faq please
- update to cpuidle <--- deep sleep is improved for me
- the simple_ondemand GPU governor is now usable and does not crash upon choosing
- fix an issue were tasks were not given properly to cpusets
- a few other changes, please take a look at my github

0.9_5
- fixed a typo which would the user not choose msm-adreno-tz GPU governor after choosing simple_ondemand <--- also have no worries I implemented a patch that will let you choose only GPU governors that will not crash
- a few more commits for schedutil and sdcardfs

0.10
- all security patches
- some patches that may help with efficiency
- many patches to schedutil,sched, and walt (many)
- few patches to sdcardfs
- tuned WALT values a bit
- other things I forgot, check my github

0.11
- I added a few additional commits to adrenoboost, it is now more conservative and suited for daily use. I run it on moderate boost and don´t notice any battery drain
- performance of the fingerprint reader may be improved <-- I need feedback from you, don´t use it myself
- update to slimbus OC
- a few patches that may help with stability and performance in general
- many patches to schedutil , it is the recommended governor now in conjunction with nohint.zip
- introduced a new governor, called helix_schedutil based on schedutil; thanks to @ZeroInfinity
I had a little play with it, if anyone finds better values I can include them.
- for more details check my github
- please check this post prior to flashing: https://xdaforums.com/showpost.php?p=71415045&postcount=210

Changelog for 0.12:
- added blu active governor
- updates to helix_schedutil, alucardsched and darknesssched
- updates to sdcardfs
- maybe some performance improvements <-- please give feedback
- other things look at my github
- made a non oc version
- please check this post prior to flashing: https://xdaforums.com/showpost.php?p=71502126&postcount=241

Changelog for 0.13
- Implemented CPU_Input_Boost by sultanxda <--- disabled by default, if you experience scrolling lag activate it in EXKM, CPU Tab
- Implemented a new sched governor called energy-dcfc (Dynamic Capacity and Frequency Capping), more information in second and third post
- Some adjustements for schedutil
- Updated helix_schedutil
- some improvements to alucardsched and darknesssched
- adjusted WALT to final parameters
- bumped up and improved BFQ, thanks @DespairFactor <-- new default
- introduced Maple I/O scheduler
- updated sdcardfs
- please check this post prior to flashing: https://xdaforums.com/showpost.php?p=71502126&postcount=241

Changelog for 0.14
- Added April Security Patches
- Updates to Schedutil, Sched, energy-dcfc
- Introduced a new EAS governor called pwrutil <-- more information on the second post
- Some upstream patches
- some more crypto patches
- updated wakelock blockers
- for other things look at my github
- please check this post prior to flashing: https://xdaforums.com/showpost.php?p=71502126&postcount=241

Changelog for 0.16
- Linux Kernel Version is now 3.18.51
- Applied May security Patches
- many other little improvements and changes


Changelog-Rebase:
- Features EAS 1.2 Machinery
- May security update
- Linux version 3.18.53
- Includes all features from mainline except the EAS Governors (sched and schedutil are included) and CPU Boost.
- IO switcher
- some patches to schedutil

1.24
Updated sdcardfs
little performance tweak
updates to low power mode

1.28
- IO switcher
- some patches to schedutil

1.29
- performance tweak

1.32
- 3.18.55
- June Security Update

1.36
- updated sdcardfs
- EAS patch
- Linux Bump to 3.18.56
- ipv6, net and ext4 patches

1.40
- Linux Version now at 3.18.59
- July Security Patches
- updated sdcardfs
- little patch for sched
- boost now also ufs storage controller upon turning on the screen additionally to boost ddr bandwidth(even faster wakeup)
- extended recharge rate when battery is near full (aids longevity of our battery)

Changelog-Harmony:

4.00
https://xdaforums.com/showpost.php?p=75835635&postcount=1105

5.01

https://xdaforums.com/showpost.php?p=76106520&postcount=1129

6.00

https://xdaforums.com/showpost.php?p=77515614&postcount=1166

6.01

https://xdaforums.com/showpost.php?p=77533981&postcount=1178

6.02

https://xdaforums.com/showpost.php?p=77588617&postcount=1180

6.04

https://xdaforums.com/showpost.php?p=77758260&postcount=1188

6.05

https://xdaforums.com/showpost.php?p=77776533&postcount=1189

6.06

https://xdaforums.com/showpost.php?p=78125103&postcount=1198

6.07

https://xdaforums.com/showpost.php?p=78342154&postcount=1209

7.00

https://xdaforums.com/showpost.php?p=78916917&postcount=1243

7.01

https://xdaforums.com/showpost.php?p=78968314&postcount=1251

8.10

https://xdaforums.com/showpost.php?p=79506878&postcount=1287

10.0

https://xdaforums.com/showpost.php?p=80581575&postcount=1301

10.1.0

https://xdaforums.com/showpost.php?p=81119421&postcount=1311


FAQ:




Q: Which app do you recommend to apply changes to the kernel?
A: EX Kernel Manager from @flar2 is a great choice. He is constantly updating it.



Q: Which CPU governor I can choose freely and not hinder the EAS?
A: schedutil



Q: what is GPU boost and how should I choose the boost level?
A: I also implemented GPU Boost.
if you use the default GPU governor which is msm-adreno-tz you will have the option of GPU boost in EXKM. if you choose simple_ondemand not.
I think GPU Boost is not really needed on this phone as it raises GPU freqs aggressively enough for most tasks. So I leave it disabled at default.
It was originally introduced on the HTC 10, to counter an issue whereby the GPU failed to scale up aggressively enough, to run some not demanding games properly in 60fps locked. But there are some performance junkies (like me) who want to try such things.
So you can enable this setting and it has 3 profiles. Low, medium and high. It defines how aggressively the GPU gets scaled up.
I found GPU boost on low to be quite a good all day setting. Maybe a little bit more performance and not a too big hit on battery.
Medium and High are definitely more battery hungry and you should do this only for gaming or benchmarks.

Q: What is the difference of WALT and PELT and how does it affect me?
A: https://xdaforums.com/showpost.php?p=71336204&postcount=179

Credits:

@Eliminater74 for bringing me into the game and the Inspiration
@flar2 for all his work
@tbalden
@savoca
@franciscofranco
@DespairFactor for the zip and the help
@Alucard24
@ZeroInfinity
@RenderBroken for helping me out
@dorimanx
@Sultanxda
if i forgot anyone just pm me and I will gladly add you

Source: https://github.com/freak07

 

[Freak07]

Info Post

So this post will be dedicated to information about EAS in general.

Another amazing write up about alucardsched by a talented new dev @joshuous:

This is what I understand from tracing the Alucardsched code. I apologise if my understanding is incorrect.

Firstly, next frequency selection with Schedutil (very simple):
Code:
next_freq = 1.25 * Max_freq * current_util / max_util;
Now, here's a quick overview of one cycle of frequency selection in Alucardsched:
1. You have two key extra tunables: PUMP_INC_STEP and PUMP_DEC_STEP
2. Current utilisation here refers to the system's current demand. It is calculated using:
Code:
curr_util = (util * (100 + tunables->boost_perc)) / max_utilisation
The "util" is a value determined by the EAS scheduler.
3. Target load here refers to what processor is currently supplying. It is calculated using:
Code:
target_load = (current_freq * 100) / max_freq;
4. The key idea is to ensure that supply satisfies demand. That is, target load ≈ current load.
5. If target_load <= current_load (too little supply), then we want to increase frequencies to match the system’s load. For Alucardsched, frequency is increased by jumping up PUMP_INC_STEP number of steps in the OPP table. (By OPP table, I refer to the available frequencies that you can switch to)
6. If target_load > current_load (too much supply), then we want to decrease frequencies to match the system’s load. For Alucardsched, frequency is decreased by jumping down PUMP_DEC_STEP number of steps in the OPP table.
7. Do note that Alucardsched jumps several frequency steps, compared to Schedutil and Interactive which try to jump immediately to a calculated next frequency. In this way, Alucardsched doesn't care about the specific value of the next speed. It's like driving a car, and deciding to increase gears by several steps instead of deciding to jump immediately to a specific gear.

Extra Tunables
FREQ_RESPONSIVENESS
PUMP_INC_STEP_AT_MIN_FREQ
PUMP_DEC_STEP_AT_MIN_FREQ
Sometimes you want the "pumping" behaviour to behave differently at lower and higher frequencies. FREQ_RESPONSIVENESS can be seen as the mark that divides the low and high frequencies. If the current frequency is less than FREQ_RESPONSIVENESS, the number of frequency skips will be PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ instead of the usual PUMP_INC_STEP and PUMP_DEC_STEP.

How is it used? If your frequency is low (lower than FREQ_RESPONSIVENESS) and your system demand is high, you ideally want to boost frequency speeds quickly. This is when PUMP_INC_STEP_AT_MIN_FREQ kicks in. PUMP_INC_STEP_AT_MIN_FREQ is usually (and should be) a larger value than PUMP_INC_STEP. When your frequency is high (higher than FREQ_RESPONSIVENESS) and your system demand is high, you don't want to be jumping so many steps up otherwise you will hit max frequencies too quickly (overkill). I'm pretty sure you can figure out how PUMP_DEC_STEP and PUMP_DEC_STEP_AT_MIN_FREQ works after having read this paragraph

Tldr;
Schedutil: simpler
Alucardsched: more tunable
Code:
IF CURRENT_FREQ < FREQ_RESPONSIVENESS:
PUMP_INC_STEP_AT_MIN_FREQ and PUMP_DEC_STEP_AT_MIN_FREQ are used
ELSE:
PUMP_INC_STEP and PUMP_DEC_STEP are used
PUMP_INC_STEP_AT_MIN_FREQ should be larger than PUMP_INC_STEP.

Note: There is however a potential problem (if you may call it one) with Alucardsched: just like Interactive you rely almost entirely on heuristics (trial and error) to control your frequency jumps instead of letting the system choose it for you, like in Schedutil. In that way, Alucardsched detracts from the goal of Schedutil to provide a simple frequency choosing mechanism. Without the proper tuning to meet your specific usage, it is likely that your frequencies will overshoot or undershoot past the needed load on Alucardsched (just like in Interactive). I would recommend that you play with the tunables to see what works best for you.

Here is information about energy-dcfc (Dynamic Capacity and Frequency Capping):

This new governor is based on schedutil. It uses target_load variables as thresholds to let the governor decide when to cap the frequencies for both clusters. These variables are called "load1_cap" and "load2_cap". Load1_cap corresponds to target_load1 meaning anything that is below target_load1, it caps using load1_cap. Anything above target_load1 and below target_load2, use load2_cap. Anything above target_load 2 and the maximum frequency will be used.

As a result of this behaviour, bit shift value must be set to 1. Anything higher than 1 and frequency scaling will be extremely slow. This is because the lower the maximum frequency, the lower the next frequency target is because the frequency range is being limited.

AS OF V009: The governor has now incorporated @Kyuubi10 's schedutil dynamic formula change. When load is below target_load1 it will use add bitshift in the formula. If load is above target_load1 but below target_load2, it won't use any bit shifting at all. If load is more than target_load2, it will subtract bitshift in the formula. This has proven to be very efficient with a touchboost-like behaviour when scrolling (Up to the capped frequency of this governor), then steady performance in between, and on heavy workloads it will not just stay on maximum frequency, in fact it will hover around 1.3-1.9GHz to ensure thermals are good as well as battery endurance.

This governor is aimed with maximum efficiency in mind. Do not expect outstanding performance with this governor.

helix_schedutil explained by @Kyuubi10

To understand Helix_schedutil you must first understand the original schedutil algorithm.
Here it is:
next_freq = maxfreq + (maxfreq >> bitshift) * util/maxcapacity

Explanation:
The most obvious difference of this algorithm is that it moves away from the idea of scaling frequencies up or down which were used in previous generations of governors.
Instead the aim of the above algorithm is to calculate the most appropriate frequency for the TOTAL CPU load.
NOTE: This is TOTAL load on CPU, not just load for the current frequency step as Interactive used to calculate with.

Now, for you numberphiles like myself that like understanding algorithms... Let's break it down:

"util/maxcapacity = Load."
The above creates a percentage value in decimal format (80% = 0.8) which represents the TOTAL load on CPU.
the algorithm now reads the following way:
next_freq = maxfreq + (maxfreq >> bitshift) * load

"maxfreq + (maxfreq >> bitshift)"

Essentially the aim of the above is to ensure that next_freq is always a little higher than the exact value needed to cover the load.

Bitshift: (paraphrasing @ZeroInfinity) in programming the ">>" mathematical function allows for shifting the binary values towards the direction of the arrows by "N" times.
In this case it is towards the right.

The relationship between "N" and the calculation in the "()" is as follows:
Bitshift = 1 = maxfreq/2
Bitshift = 2 = maxfreq/4
Bitshift = 3 = maxfreq/8

If the "+()" didn't exist in the algorithm, the chosen frequency would be exactly enough to cover the load.
If load is 0.6, aka 60%, all you need is a frequency = 60% of max frequency.
This would be bad since it doesn't leave any capacity/bandwidth leftover for inevitable bumps in load, nor space for EAS itself to run. Thus inevitably creating lags.
To keep a bit of free bandwidth you add "(maxfreq >> bitshift)".

Finally the problem I encountered, if bitshift = 2, then the result of the algorithm is that any load above 0.8 will result in a next_freq HIGHER than maxfreq. - This is your tipping point. As any load higher than 80% will wake up a new CPU.

Which means you have still about 20% of the CPU's max capacity being unused. Such a CPU is only 80% efficient.

Therefore by increasing bitshift to 3, the algorithm reads:
"maxfreq+(maxfreq/8)*load = next_freq"
This way you can use 89% of capacity before reaching max frequency of the CPU.
With bitshift=4 it reads:
"maxfreq+(maxfreq/16)*load = next_freq"
This allows you to use up to 94% total CPU load before reaching max frequency.
While this is great for improving efficiency at the higher frequencies, it doesn't leave enough bandwidth when calculating lower frequencies, and creates lag when load spikes at lower frequencies.

Update to the explanation:

After being inspired by the concept of @ZeroInfinity's new governor - Energy-DCFC, I decided to carry out a couple of tests on HTC 10 using variations of Helix_Schedutil.
The focus was stress-testing by increasing the current frequency load above 100%. (AKA Use up all of the bandwidth of the current frequency step.)
After the testing me and Zero worked on this new version of Helix_Schedutil.

The current behaviour of the governor is the following:
- Boost frequencies when load is below Target_Load1. (Boost can be increased by DECREASING bit_shift1 value.)
- Between Target_Loads there is no bit_shift at all. The governor just uses the following algorithm instead - (max_freq*util/max = next_freq)
- Loads higher than Target_Load2 will be THROTTLED. Bit_Shift2 here is subtracted rather than added. (Throttle effect can be increased by DECREASING bit_shift2 value.)

The result is that low freqs have spare bandwidth to avoid lags, middle frequencies leave no extra bandwidth at all, while higher frequencies are throttled to save battery.
Another focus of the governor update is to reduce overhead as much as possible. This results in a very responsive governor which isn't overly demanding on battery life.
Schedtune.boost values recommended for use with this governor:
Top_App: 5
Foreground: -50
Background: -50
Global: -50

Energy-DCFC is still recommended for those who prefer battery life over performance, but if you prefer greater performance then this governor can be used without making you feel guilty about wasting battery.

correction a misconception:
Some people describe tipping point as the load threshold which the governor uses to decide whether to ramp up or down.

While if you look into the behaviour of the governor it may appear that it behaves in such a way, it is technically incorrect.

As I mentioned previously this new algorithm moves away from the behaviour of legacy governor algorithms which focus on the current frequency load.
This governor does no ramping up or down.
It isn't even aware of the current frequency load, as it only knows the load relative to max capacity.

The misconception appears based on a property of the algorithm that results in a consistent load at any chosen frequency. This is a coincidental result of the algorithm, even though the algorithm is completely unaware of it.

Tipping point is in fact the load percentage at which the CPU reaches max frequency and any increase in load forces it to wake up a new core

here is some Information about pwrutil governor:

This new governor is based on schedutil.

A much simpler yet very effective governor based on schedutil. All this changes is the calculation to get the next frequency. Rather than using bit shift to calculate tipping point and what not, we don't use it at all. This is much much more efficient if you use my program called "schedutilCalculator" to calculate what the next frequency is. For example, a load of 25% with a max freq of 2150400 will get 500MHz as next frequency. A load of 50% will get 1GHz as next frequency. A load of 75% will get 1.5-1.6GHz as next frequency. A load of 100% will get 2.15GHz as next frequency. You can see the lower the load, the much lower the frequency selection will be, but the higher the load and the higher the frequency selection is. So it can go from a very low powered state with 50% load and under, to a high performance state from 75% load and above.

Includes a tunable called "utilboost" which is basically a load multiplier - it makes load higher than it is perceived by the governor, thus making next frequency selection higher. Remember utilisation does not equal load. The equation of calculating load is util / max capacity of a CPU (which should be 1024). So 512 / 1024 = 0.5 (50% load).

UTIL BOOST IS NOT MEANT TO BE USED WITH SCHEDTUNE.BOOST AT THE SAME TIME! EITHER USE ONE OR THE OTHER OR ELSE PERFORMANCE WILL BE OVERKILL AND BATTERY LIFE WILL DRAIN MUCH FASTER!!!
Util boost is supposed to be a replacement of schedtune.boost. schedtune.boost applies boosting to both clusters, whereas util boost allows boosting per-cluster so users can have much more control.

 

[Freak07]

how to gather logs:

There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)

ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4


ramopps:Some Documentation on Ramopps

Normal Logcat:


Radio Logcat:


Ramoops:

Via adb:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt

Via terminal on phone:
su

cat /sys/fs/pstore/console-ramoops > /sdcard/kmsg.txt

Kernel Log:


Kernel Log:
adb shell su -c dmesg > dmesg.log

Last_Kmsg:NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log

NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).



PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://xdaforums.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat

I only Revived it a bit for ramopps.
I will update this more at a later time..

 

[557953]

Excellent work my friend thanks for supporting the Pixel XL I hope you get lots of joy from your new hobby!

Will flash in the morning and see how it goes...

 

[franciscofranco]

Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary

 

[almightysiman]

can you disable storage force-encryption？thanks！

Sent from my Pixel XL using XDA Labs

 

[ghostENVY]

Are the safetynet patches implemented by any chance?

 

[Freak07]

Most of those audio patches you backported seem to be interesting, specially the ones that are meant to reduce power comsumption. Will pick. Suggestion, you don't need to specify the slot in the fastboot command, just fastboot flash kernel kernel_binary

When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.

 

[Freak07]

can you disable storage force-encryption？thanks！

I will look into it.

Are the safetynet patches implemented by any chance?

No I didn’t implement them yet. I will look into it.

 

[xocomaox]

Let us know when you'll have a flashable zip for this! Sounds good!

 

[Reechings]

Thanks for another kernel option!

Sent from my Pixel XL using XDA Labs

 

[franciscofranco]

When I did only fastboot flash, I ended up twice with a system that somehow didn’t know which boot slot to boot to.
Each reboot it would boot into the different boot slot. The only thing that resolved this was to flash the factory image from google.
Even specifying the boot slot via fastboot did not alter this behaviour.
Somewhere in the q & a section someone is describing the problem too. It occured the first time after using fastboot flash kernel command.

Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...

 

[Freak07]

Well, I've been using that command since day 1. I've flashed countless times, it never failed to boot once...

are you running stock rom? I believe you, if you say, you never had issues.
I ran into the issue I described earlier. It would Change Slots upon each reboot and nothing except flashing back stock Google Image fixes it.

 

[Freak07]

new kernel 0.2 is available

I added safetynet patch and another commit that may help with Performance

Download is here or in the OP
https://www.androidfilehost.com/?fid=529152257862702410

 

[Player-J]

It's great to see development for our beloved Pixel XL! I'll be checking this out. I thank you friend!

 

[CZ Eddie]

It also includes a few Audio Patches from CAF.

Anything related to aptX Bluetooth?

 

[Freak07]

Anything related to aptX Bluetooth?

Don’t know. What are you searching for exactly?

 

[Freak07]

Hey

I updated the kernel to 0.3

Main changes are:

- Add GPU OC to 652mhz like the performance edition of our soc
- Update wake gestures
- Many new Performance Patches
- Updated dm verity

Download is here:
https://www.androidfilehost.com/?fid=745425885120707916

 

[Alcolawl]

Lots of sweet features and commits. Definitely keeping my eye on this kernel. :good:

 

[Reechings]

Can you make it TWRP flashable please?

Sent from my Pixel XL using XDA Labs