yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
BINDER TEST BUILD:

* Latest code from both of my branches *WITH* binder changes/switch over; built from my binder branch. This is NOT the next RC ~ this would be for people who would like to help test my binder branch with me. I've had ZERO crashes from Google Camera (in either branch).... *If you do have a crash - before reporting, please wipe Google Camera data, power off the device ~ then test again.... After that, if it crashes let me know (it shouldn't).

https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_binder_edfc17c.zip

There may be other bugs; but what i'm testing here is; Google Camera not crashing. It still may drop the odd buffer, or render incorrectly - those are separate issues that *will* be addressed later.

Now, for those who would like the next RC build (stable/beta channel, no binder changes);

I will be posting the RC3 build in 3-4 hours.... * Just so I can run it for a few more hours before posting... The RC will (hopefully) replace the OP Download ~> Once it has had some good testing. My goal is to have it become our first "Stable release".... I tested it for a few hours this morning, but would like to test it a bit more before posting....

So just bare with me here, I've spent most of the last week - rolling back branches, then having to start over twice now ~> before finally ironing out things... I've done 220+ commits on my new branches in 3 days => It's taken great effort to solve a number of issues, google Camera has been a huge hassle and stress for sure, etc, etc.

Lastly, do NOT make a big fuss over any Battery statistics/issues, until you've given one of these these kernels a run for several days... The reason, you may ask??? ;

1). Stability is #1 ('ve needed to resolve a ton of underlying issues and the Camera stuff)

2). There could be regressions and there is still some yet to be merged code.

3). AccuBattery, BatteryStats, etc do NOT give accurate results given only a day to run...

4). I'm not done merging in EASv1.4 + a few tweaks.

5). Losing 10-15min of battery life over a 24hour period is NOT a big deal. Kinks are still being ironed out. *other kernels do NOT have some of the run-time hardening that my kernel does. There is overhead.

anyway, I'll post the RC3 build in a few hours. In the meantime, anyone is welcome to try out this build. * but DO report back good or bad news ;)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
RC3 TEST BUILD:

Here is the RC3 test build (no binder changes);

https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_RC3_a69f7ff.zip

Latest code from both branches (minus Binder driver code). The big changes are;

- the vast majority or EASv1.4 merged

- Maple IO scheduler

- Cpu-boost / Input boosting is (somewhat) supported.

- linux-3.18.81 LTS

- major gutting / refresh of my kernel sources

NOTE: Until the next build, Input boosting is not persistent across reboots. Regardless, to test Input boosting; in EXKM - goto; CPU->CPU Boost Options

- Input boost enabled => select enabled

- Input Boost Frequency => the defaults should be changed (i set mine to the highest frequencies)

- Input Boost milliseconds => set somewhere between 40-100

* Input Boosting *could* affect battery life (because you are changing the cpu frequencies to be higher on touch).

* Input boosting should improve game play and responsiveness

* it's possible that it still might affect the low latency audio path - but so far, that isn't the case with any of the apps that I test against. i've been very happy with Input boosting, thus far.

Any problems with Input boosting, please let me know - this feature seems stable now - but testing is still underway / required before I change my init.exenoshadez.rc to NOT disable it on boot && set some defaults.

Regarding Google Camera, same applies as above - don't report crashing unless you've cleared Google Camera's data, powered down your pixel and then restarted (this should only really be necessary coming from a binder test build, but still - do it anyway, if you encounter a crash)....

happy testing!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
On the radar / coming changes (in both branches):

- a round of non-user facing bug fixes && code cleanups

- audio driver backports + improvements

- merging in missing bits from my older retired kernel branch

- begin moving kernel subsystem updates into new branch (won't happen until after a stable release or three)

In the Binder branch *only*, once I can get the missing kernel function that I need into the kernel;

- update Ion and Binder (missing bits to match AOSP / upstream)

- fix any bugs with binder in my current binder build. (the above will do that, probably)

- implement kernel compile-time Kconfig option for Binder/Ion (binder RT, more geared for low latency apps, like proaudio). *experimental* => won't be enabled in builds.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
I am running the binder test build, all is running great except this.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
hey, yes. I'm aware that zram is crapped out. I may actually just disable it (I think it is arguably, fairly useless to begin with)...

so u decided to jump unto the binder build eh?. .... it is pretty stable. every once in a while I get a glitch with the camera previews, image flipping or artifacts... but that'll be worked out AND doesn't affect the RC3 build....

*both should be fairly rock solid, at this point... binder build may have the odd glitch hiccup, it's a 98% port - need that last 2% ? ... still 'good enough' for me to use day to day though.

Thanks again, keep me posted.

also; I've merged in some code, will help battery life. it'll be in the next build... I'm still getting some of that stuff staged, but it's running on my device now
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Yes it works well, 3d games all work well. I have had no problems with the camera at all. Testing battery life now.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Cool. ya, gaming should be good - have you tried out input boosting? ... like with games n such? ... i tested it with egl demos, higher fps and response for sure...

yeah. the camera bugs/glitches are hard to trigger, require a lot of buffers being thrown around, etc.... there are no camera crashes though; i found / fixed the cause, 99.9999% positive. lol.

just keep in mind, next build WILL have better battery life. i hadn't merged in some commits on your build yet...

getting stability back / no stupid camera crashes, fault addr bs. lol... that's what these 2 test builds are all about.... I just need a few good reports and I can merge in some of the staged patches and promote the RC4 to stable instead.

note; I will continue to post binder builds too, the two branches are largely sync'd, just the binder driver is different. so easy to compile / post both builds...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I've been taking a closer look at this => zram and exkm ....

exkm seems to be hitting against selinux and is being denied access to sysfs_zram ....hmmmm.

zram is mounted / swapon ~ I checked... You can also still adjust zram swappiness ~ but the rest of the options appear to be blocked / not allowed access, at least in exkm. ~ I'll have to look more into this - but I'm not overly concerned . but it is a minor issue, that I will fix...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
-> next build should be better on battery life.

-> on idle a few % less cpu load (working on ways to reduced this more)

-> input boosting becomes enabled b default. Sets itself to 1324MHZ both clusters

-> Input boost frequencies can be changed per cluster (in exkm / save settings)

-> I've removed disabling input boosting on on boot (should be persistent now)

i'll probably get a few other bits merged in before posting another build though ~ and I'm still waiting for more feedback on the non-binder build / RC3 ~ I'd really like to push the next build of that as Stable, not an RC...

Followed by the thread title to reflect that we've arrived at stable, update my notes a bit (although I have been), etc....

I personally feel that the kernel has really stabilized in both branches, I haven't introduced any unpredictable or untested code, beyond some EAS changes - but that's only a small handful, that I've been testing for days and days... Everything else, I already am very familiar with, used on my previous branch....

So hopefully, a few people are home today, later or whatever and can test run the RC build. Then I can push a new (stable build) and new binder test build.

zram still not sure what the selinux denial is all about. but zram IS doing it's thing (verified). Just not visible to EXKM. hmmmm....idk yet.

EDIT: 99% sure I'll be marking the next build as Stable - regardless of feedback. Heck, my latest Binder build from today is solid as can be! ;)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
NEW BUILDS ARE UP (on the OP too).

Stable Branch: https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas-3.18.82_Stable_053270f.zip

Binder branch: https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_3.18.82_Binder_053270f.zip

Yup. I'm marking that as stable. My friend has been running it for 24hours, zero problems. I've been PM'd by a couple of people and I had a couple of emails too about it too.... These builds are the exact same, minus binder drivers.... I tested the Stable one all day - now I'm back on the Binder build (which I prefer, it's snappier)....

Changes;

- linux 3.18.82 LTS

- Everything listed in the above post

- This one should be nicer on battery.

Feedback would be good.

Honestly, Binder build is awesome. I haven't run into a single problem. I'm just hesitant to make it the default build, until I can get it sync'd with AOSP. But i'm having a hard time getting the last few patches merged in.... but yeah, It's faster, punchier, seems better on battery and efficient....

So I'll keep at it, maybe in the coming weeks I can get the last Binder code and linux code needed merged in and tested. I would really love to just ditch the Marlin Binder driver and move on. lol.... There are still at least 3 EASv1.4 patches to merge in - 1/2 cause bootloops, one I do not believe our older kernel has what's needed, may require some kind of new function or backport. not sure ~ but thus far, it hasn't been a critical issue...

enjoy.

EDIT: Please also read the OP I've updated all information on that page.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Horgar:
Been using your RC3 build for 24 hrs now and no problems. Camera fine, no crashes or FC. I think this build is speedy but will try your binder build tomorrow if you think it's even better.

Thanks
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I do think the Binder build is better for a few reasons (cited in the OP and just discussed throughout the thread). But I would say go with whatever makes you feel comfortable, is stable and works for you ~ i'll be providing both builds all of the time now.... There may come a time when I can ditch / replace Marlin's binder ~ but for now, It's still not a full port from AOSP - still needs work (but actually has been quite solid and stable for me)

Glad to hear that you've been giving it a good run. The impression that I've gotten is that both builds are very stable now... no problems....

I'm taking it a step further - and just build my binder branch with rt_mutexes again ~ if things are going to crash and burn - it'll be exposed on this build, I would tend to think. So far its _awesome_ ~ but it's probably a battery pig....lol...

Definitely better for low latency audio / multimedia though... heaps better.

so I'll spend the rest of today tomorrrow, trying to crash Binder on this build - maybe I'll stumble across something useful, like a patch that I find due to something I bash into with this build (that's kind of the point)....LOL

anyway, thanks for the report / feedback ~ keep me posted - I'm always interested in hearing the good and the bad. observations, etc .... it's all great stuff! ;)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So on my github sits another build of Binder. The kernel itself is the exact same as the stable and Binder branch, but this particular implementation of Binder is aimed at having a more high-performance, deterministic, low latency Binder. (

I call it; "Binder RT".... I highly doubt most people would want to run this build "day to day" on their device (it probably chews through battery and cpu cycles, although I might run it or a variant of it...)...But it does give THE best performance out of all of my kernel builds. In particular, due to its fast IPC, shared memory acces (ashmem) and having replaced all mutex (locks) with rt_mutexes ~ it is very ideal for low latency pro audio, interactive and/or multimedia apps.

I know some of you may not understand why I put so much effort into Binder and rant about it, but if you are REALLY curious would like to learn => then I have a really easy and fun way to showcase why that is (*that you can quickly observe for yourself*). this little demo will instantly show the importance of having a good Binder implementation to work with (even Marlin vs. current AOSP implementation).... It will take you 10 minutes to try out ~ and I think you would instantly "get it", after trying this demo ;)

So, if at all interested. Follow these Instructions;

1. Go to the play store and download this app; https://play.google.com/store/apps/details?id=com.ovalsound.Oval

2. using your current running kernel (doesn't matter what kernel it is). Open this app and tap on the musical pads... select different sounds, play around for a few minutes ~ you will notice stuff....observe and keep those things in mind. lol. ;)

3. Next, install the kernel Linked below (Binder RT kernel).

4. Reboot and open that same app and run through step #2 again....

Did you notice anything different this time around?

I'm guessing you might.

Experimental Build: https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_Binder_RT_c1140cd.zip

Remember - it's a 10min process, you can flash back your other kernel after. no big deal :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Does anyone notice Android system held awake the device for so much of time?or it's just me.I am on the exNoShadez_eas_3.18.82_Binder build.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I've never experienced that. 35min seems pretty crazy.

do you have any ideas on what the cause might be? ... or maybe something that could be at play?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] marioemp2k7:
[MENTION=7721249]almightysiman[/MENTION] Are you sure that it's not the Google Play Services at fault? I've had this issue multiple times on different builds (twice on October and once on November security updates). What worked for me was to wipe the data of GPS and reboot. If the reboot hangs somewhere along the way, just force reboot it again and it should work.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
GPS is generally annoying, nothing to do with my kernel... it used to like chewing through my data, as well... used to really irritate me... that was on stock kernel... wouldn't be a factor though.

personally, if using Magisk; I recommend using the 'enable doze for GMS module'... I also block it from using background data.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Colday96:
I have an unlocked bootloader with the permanent twrp installed. Do i just need to flash this kernel and reboot?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Please read the OP / first post. It covers this and other important details.

TWRP cannot be installed to the system - TWRP requires being in stall in the boot partition and cannot be installed (there isn't room for it, due to the kernel needing the extra space).... You must remove it (instructions on the OP), then use the fasboot twrp boot.img (which loads into memory) to flash my kernel....

So your first step is to replace the boot.img with stock boot.img using fastboot -> to remove TWRP from your system. Then you can flash my kernel...using twrp.

1. use fastboot to install stock boot.img

2. fastboot into twrp

3. install my flashable kernel zip

4. magisk, supersu... or any other zips.

5. reboot

I explain the reason / design choice for why I don't support permenant TWRP installations with my kernel. (there are valid reasons for it).

Lastly, if you don't have a stock boot.img and don't want to download the sailfish firmware image to get it, let me know - I can provide it. not a problem. => ***EDIT: I uploaded and put a link to the Nov stock boot.img, if you need it - it's in the OP section on removing TWRP from the system.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Well I am on the RT binder, battery drain is no more than others, no crackle at all with the sound on games and heavy loads. So snappy and fluid really like it. Even with my heavy use I get 5 hours screen on time and no drain overnight.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Aha. You decided to try the RT build, eh? nice.

I'm running it too... I just assumed it would drain more battery (because of of the changes to locking in Binder, Ion and Ashmem), but yeah, it's the snappiest build, without a doubt - no contest...

actually, I'm also in the process of adding a proper kernel configuration for binder_rt, as well.... In the short term, I'm wrapping all of the mutex functions... If the kernel defconfig contains CONFIG_ANDROID_RT=y, then it substitutes in all of the needed rt_mutex code... This doesn't really matter / affect end-users but it would mean I could have just one Binder branch - rather than 2 separate branches, which would be better for me.

Also, in the future; maybe it would be possible to implement some runtime sysctl control ~ Like one could tick it from 0 to 1 and switch to rt_mutexes (that might blow up though, I won't know until I try) - or set it on boot (which might better)... I could probably add it in with CPU-boost or place it in /proc/sys/kernel or something.... Haven't even look into this yet - just an idea.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
That was my experience lastnight too. but I just know that rt_mutexes usually do incur overhead penalties... Maybe it's just not too high, with this kernel on android, using schedutil, threaded interrupts, etc ....

It's hard to say and since this is essentially my own Fork of binder / notable differences from other implementations, it's kind of a 'no man's land' situation... Will require some time for me to figure it all out....

But on a general note: it does seem to be working quite well, no issues that I've encountered yet.

Also: I've finished wrapping all of the functions and adding a Kconfig for CONFIG_BINDER_RT... I haven't merged it into my Binder Branch(yet). But I'm in the position, where I can now (just gotta lump all of the binder_rt commits into a single commit / clean ups).... So that's pretty awesome. Nice thing - is that there are no code changes or functional changes - so it doesn't impact the Binder branch (when not using CONFIG_BINDER_RT) at al ~ business, as usual...

So whenever, I get to it - I can start investigating making it a run-time option... doubting that'll work out, but whatever.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Colday96:
Deleted
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
that could be. I'm sitting on some changes / bug fixes to KGSL, mdss yet - it's possible that they may iron that out.... There's a lot of string usage in the settings app - how about trying an app like google earth ~ where lots of stuff is actually being rendered to the screen.

PS: Which kernel - it probably matters

edit; I do observe the same thing, however, under system load (playing video/audio in the background), it drops quite well below. that makes me think that it has to do with scheduling code;

this could be do EAS / scheduler changes (sched vs. schedutil) not present in stock. it could be something else....

now that I've got the FCs all sorted out - this is the kind of thing that I can investigate... I'll roll through my kgsl, mdss, etc bug fixes - as well as testing some theories out...

sound good?. ... thanks for bringing this to my attention.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] phaino00:
Not good. I believe you bricked your Pixel. You may want to contact Google for an RMA replacement.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
you've bricked your phone.

yup. u messed up big time. NEVER EVER re-lock your bootloader when running custom kernels, ROM, firmware, etc..... I have ZERO idea why you would decide to lock your bootloader but that was a terrible idea....

I'm not trying to make you feel bad, but that's a huge no-no, you shouldn't have even considered doing that...

I can't help you, unfortunately .... and just to clarify; There would've have been no advantage to locking your bootloader, locked bootloaders are for Stock - when you don't plan to root, use custom kernels, sideloaded software, fastboot, twrp, etc, etc...

[MENTION=3097488]phaino00[/MENTION] is 100% right.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
So aside from user induced issues (Coldplay96's problem which I feel terrible has happened)...

reports have been really positive - both on this thread and elsewhere. :)

There is still the issue of EXKM not having permissions to view ZRAM - but I can assure you that ZRAM is functioning just fine. IMHO, you really shouldn't ever have a need to alter ZRAM settings anyway. You would need to run out of memory and swapping to occur before it ever was an issue ~ and I think the defaults manage ZRAM just fine... I believe that some changes brought in with EAS to crgoups are responsible for the denail ~ but I won't be reverting EASv1.4 changes to allow EXKM to read ZRAM settings... maybe a workaround will turn up... Still investigating, but low priority.

The GPU profiling revealed that EAS changes may be dropping some frames when the system is largely IDLE, but whenever it's under load - this goes back to not droppping frames ~ for all practicality - this is more than acceptable to me - but it may be something that I look into improving as things progress.

Aside from those points - all of my kernels seem very stable now. No big issues on any branch ~ even the RT branch is quite stable. (although, I did merge in a bit of code today for it. nothing substantial though - no need to put up a new build yet).... Since it appears that there are some enthusiasts interested in using the RT branch ~ next set of releases, will also include the RT branch build on the OP ~ going forward, I will support all three builds.... Personally, I've switched to using the RT branch due to it better supporting some of the apps that I personally use....

With things stabilized, I'm going to try and get the remaining Binder commits into those two branches, as well as the remaining EASv14 and a few bug fixes committed. So at this point; development will slow down a bit (after a solid month of putting this kernel together)....

But if you do happen to bump into any problems; make sure to let me know.... ***battery life is in a much better position to be evaluated now too, if that's your cup of tea... Any tweaks that I can come up with to improve battery life - I will try to get in, but they are always tricky and I'm trying to avoid a ton of downstream / one off patches - as I've found they tend to introduce other regressions....

also, just general perspectives or experiences are great too....