yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
@ グリッチ - if you like you can try out this test build and see if the front camera recovers / doesn't get hung. your call.

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

This isn't ready for prime time - as I *can* make Google Camera crash with it - usually by snapping a bunch of pictures, switching to "lens blur", then switching cameras back and forth ~ one call in binder still needs to be made asynchronous and i _think_ it will stop the collisions, but I mention / post this; because I am curious - if your camera recovers...

NOTE: everyone else if you aren't experiencing the front camera issue - don't flash this one. It is a bit snappier, but (for me anyway - I can crash Google Camera - but couldn't on last build).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
@ グリッチ - if you like you can try out this test build and see if the front camera recovers / doesn't get hung. your call.

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

This isn't ready for prime time - as I *can* make Google Camera crash with it - usually by snapping a bunch of pictures, switching to "lens blur", then switching cameras back and forth ~ one call in binder still needs to be made asynchronous and i _think_ it will stop the collisions, but I mention / post this; because I am curious - if your camera recovers...

NOTE: everyone else if you aren't experiencing the front camera issue - don't flash this one. It is a bit snappier, but crashy (for me anyway - I can crash Google Camera - but couldn't on last build).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Ok... So; I'm prepping for another update on the OP download...

This update *won't* integrate the New Binder => but will revert it to the old/stock binder + a few minor bug fixes and tweaks... Because the new binder just isn't ready for prime time / I need to spend a good amount of time working on it ~> I've created a new branch, where I will continue to work on it, instead...

The next OP download WILL include a subset / most of the locking/scheduler changes, some bug fixes (I have a couple of handfuls) and cleanups... What I've done is created a branch that rolled all of my commits back to 3.18.79 ~ I then applied the upstream updated (LTS/3.18.80 ** Oreo Nov Patches)... Now , I'm in the process of cherry-picking (and cleaning up said cherry-picks) into that branch...

To make life easier - I've also added a little file into the kernel sources to help me track commits; it just verifies where the locking/sched code (or other subsystems) is currently at... (it's impossible to tell from just commits... ~ I'm going to walk through all of this slowly with lots of testing, before moving forward with merges... I also need to document some new kernel config options and also new functionality that could be implemented elsewhere (my tracking file will document these, as well && point to the related kernel documentation)...

This way, I can work on stabilizing everything - without dealing with the Pain of Google Camera + a new version of Binder ~ Which I will chip away at in my other branch, as time permits....

anyhoo, I'll probably post a test build within a day (as a candidate for the OP download / stable),,,
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Colday96:
How does this kernel compare to the stock Oreo kernel? I am on the stock Oreo factory image and the battery drain is horrible with also terrible performance

---------- Post added at 12:03 PM ---------- Previous post was at 12:01 PM ----------

And also, how much time will it take you to start working on steps 3 and 4 ? If you need any help, I can test build for you :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
I find that RC1 build have disable gesture,Can you enable It?It's a really useful feature.Thanks and keep up the good work!

Edit:God!this latest build is running fast.:good:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] billiepreks:
Aha you're amazing ! But I've to confess : I've found your kernel when I've searched for binfmt_misc support, but I've seen AFTER your kernel is for Oreo, however I'm stoll on Nougat for now.

But now that I've learned to do without Xposed (Yeah it took me some time), I haven't any reasons anymore to stay on Nougat. So let me some time to understand the Oreo knowledges, and I'll get back to test it. Thanks you ! :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] グリッチ:
Just wanted to say, I haven't had a single camera crash since I disabled the substratum theme (not saying it was the cause or even related), just that since then all has been well. :D

I did notice something else though, bizarre hiccup... I unplugged the charger during the reboot process, don't remember exactly where, probably in the bootloader screen or the white boot logo (not the boot animation because my boot animation is black)... and it just stayed frozen on the white screen, had to hold VOL UP and Power to reboot it again. Dunno if that's kernel related or if my phone is just already showing signs of aging lol

Also another question: I've seen people around these forums saying it's not good/stable/reliable enough to install twrp zip and instead keep it stock and boot the twrp img if I ever need to use TWRP. Til now I have been using the img, but just wondering if it's still the case for this kernel, can I go ahead and install the twrp zip? What do you do when you update/reflash your kernel? I usually plug it in pc, fastboot a clean boot.img and boot the twrp and then install kernel > magisk > reboot
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I was having odd 'hiccups' like that with the binder 4.4 code and the odd issue with the camera ~ it's definitely not ready for prime time.... it works *mostly", but still a bit buggy for now ~ that's why I decidedto roll things back and work on it for a while in a separate branch until I get things ironed out....

No, you can't install TWRP with my kernel. #1 - I Don't want to support that #2 - TWRP installs itself in the boot partition, which is very small - my kernel is large, it isn't optimized for size, nor should it be (hint: stock kernel isn't either, but mine is fatter than stock).... TWRP will fail to to install - it's all on the OP. Why I don't support it, how people do support, my motivation with that, etc, etc.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Sorry man, Yes - I can re-enable it ~ When I rolled back the code - I just forgot to re-enable it. Next build will have it... Ya, this build isn't too bad - I've vcleaned up a few things, by rolling it back and redoing a few things...

haha. I hear you on the xposed thing. I haven't used it since Lollipop though. At the time, I was using CopperHeadOS's exec spawning model (like traditional linux) rathern than android's 'fork only' approach with zygote.... ~ It made running xposed impossible - I ended up grabbing funtionality from a few xposed plugins and baking it into my ROM... On the Pixel, I just haven't found much of a need for xposed. I get most of my customization from elsewhere, plus (and im not surre if this is the case anymore ~ but I dislike the notion of deodexing a rom).

yeah, try binfmt_misc out and let me know. I haven't tested it - Linux Desploy fails on another step - I don't think it likes magisk or something. SuperSu is kinda crappy though - not replacing magisk to try linux deploy, so.....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Sorry man, Yes - I can re-enable it ~ When I rolled back the code - I just forgot to re-enable it. Next build will have it... Ya, this build isn't too bad - I've vcleaned up a few things, by rolling it back and redoing a few things...

haha. I hear you on the xposed thing. I haven't used it since Lollipop though. At the time, I was using CopperHeadOS's exec spawning model (like traditional linux) rather than android's 'fork only' approach with zygote.... ~ It made running xposed impossible - I ended up grabbing functionality from a few xposed plugins and baking it into my ROM...

On the Pixel, I just haven't found much of a need for xposed. I get most of my customization from elsewhere, plus (and im not sure if this is the case anymore ~ but I dislike the notion of deodexing a rom and at one point, that was needed for xposed.).

yeah, try binfmt_misc out and let me know. I haven't tested it - Linux Desploy fails on another step - I don't think it likes magisk or something. SuperSu is kinda crappy though - not replacing magisk to try linux deploy, so.....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
A bit of a development update;

As part of making my kernel easier to build (and also to make sure that all of my tools and configurations are backup'd off of my linux box), I'm in the process of adding the necessary bits to my github;

https://github.com/nine7nine/AnyKernel_EX-Noshades-EAS

It provides AnyKernel2 (osmOsis build) already setup for my kernel, with instructions, on how to build a flashable zip with my configuration in place....

Next, after a rebuild of my toolchain - I'll probably provide binaries for;

aarch64-linux-gnu (GCC - Linaro 7.x.x development branch)...

...along with links to the github, that I use to actually build the toolchain/compiler.

I still discourage building from my github - because things periodically do break - although, I'm getting more focused on changing my workflow, so that doesn't happen as often... Also, it isn't helpful - if say, you build the kernel slightly different, then report back issues - it'll just cause confusion...

Nonetheless, I would like to make it easier for anyone who is actually interested in getting involved (like contributing, doing pull requests, fixing bugs, etc). So a few steps are needed to make that happen.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I would suggest that you just try it out and see. You can always re-flash to stock boot.img - if you don't like it ;)

If you are game, please try this build; https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_RC1_44994a5.zip .... It is the current test build / RC (release candidate).

It should be fast, performance should be reasonably good. But there is some overhead (in particular on this build - because I added some code that does some hardening/security stuff during runtime, so battery may be a bit reduced to (vs. my previous builds - not talking/comparing to stock, at all)... I'm kind of in the middle of rolling back/re-integrating some code - So a few bits will improve; leading up to me updating the official build...

steps 3/4 were related to my other dev/test builds that use some code (a fork of binder) not present in my current test build ~ it isn't quite stable enough yet, thus I'm not including it, until I've worked out all of the kinks...or 99.99999% ;)

This build should be quite stable. no crashes of the camera app or anything like that... It's possible something stilll might crash or hang, but I haven't had any issues like that ~ and the code responsible for that before is gone. (but that's why it's a test build. lol)

Steps 4/5 are an ongoing process - no ETAs please... You may not realize the complexity to some of this stuff and sometimes improvments happen quick, sometimes they are small and incremental. ie: it's a process...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION] - I may have a an RC2 test build later on.... Changelist will be;

- Wake Gestures re-enabled.

- Some EAS merges / fix ups.

- other misc bug fixes (re-merged from dev branch)

- possibly some scheduling code

- possibly a fixup to the wifi driver

- other misc bits and pieces.

- batterystats accounting should be corrected too (it's slightly off in the test build).

I'll try to get to it later tonight ~ but gotta run the build after my next few changes for the rest of the day / poke it in all of the right places - make sure everything is good, efore posting.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Sooo.... it

appears

that it may, in fact, be some EAS related code that was causing the camera crash in my dev / binder branch.... I bumped into this while re-merging in some EAS stuff into my main branch ~ pending more testing, I may have fixed this now. (the code isn't in the main branch, so no worries, no camera crashes. lol)

On a related note: there's also a use-after-free bugfix for binder applicable to by dev/binder branch (and afaict, our binder too. will check later).

gotta test both branches AND recharge my phone (didn't charge it last night and drained my battery slamming my phone to see if I could make anything crash. lol)... definitely more focused on the main branch RC stuff, I'll fully test the dev branch (for camera crashes), once I get a new release out for the stable/beta.

anyhoo, making progress for the next RC2 build. several fixes, getting some of the EAS stuff back in order, post-rolling my kernel sources back... still have a few things to do and a round of testing, prolly push a test build, but not until way later.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
New test build:

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

Changes:

- re-integrated a number of EAS commits,cleanups and a few new bits.

- some bug fixes not in RC1 (fixing a hang/FC that I would hit periodically)

- Wake Gestures enabled

- fixes in scheduling code

- reverted ANDROID: sched/rt: schedtune: Add boost retention to RT" patch

Recommended to upgrade from RC1;

- this build properly calculates BatteryStats

- should reduce any battery drain from RC1

- scheduling code fixes (if you hit an FC, it is probably fixed in RC2)

- I found RC1 ran a bit 'hot', but not in this build.

I've got some other things that I'm working on, but I feel that RC1 was a bit of a battery pig and since I did bump into a hang/FC - it's time to post an updated test build that resolves some of the immediate issues.....

reports back, always welcome... Again, if you were on a previous test build that had my binder changes - disable Google Camera, then re-enable and upgrade. thx
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Interesting - While I'm not rolling binder 4.4 into this build, at least not until I'm dead positive it won't crash AT ALL.

*I am currently running it on my phone ~ no crashes as of yet. I decided to try it out on the rolled back (now main branch), because it doesn't I caught a commit that I think may have caused the problem, in the first place - and fixed it....

So who knows, but; while I work on the RC's I am going to continue to try and use binder 4.4 on the same builds (while i'm not testing). Maybe in a week or so ~ if all is well, I can add it back... that would be nice - because some of the power saving and performance stuff - comes from that build of binder.... much nicer than 3.18 binder (excluding the camera issues/bugs - but.... again, so far - I've yet to crash the camera or any other app using it).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Just wanna to report back,The idle drain overnight is normal again with Rc2 which only drain 0%-1% battery.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Cool.

I actually will have an updated build soon ~> I started a new branch, essentially rolling right back to befor any of my commits. Then I sync'd up to all of my remote branches and started from scratch (I was hitting a few bugs that were driving me up the wall... and my original branch just did a few things backwards, lots of derpy commits, etc = hard to track down issues that may have snuck in a while ago....

I'm caught up now (actually ahead of where I was). I'm almost caught up to EAS v1.4, as well. ~ but there are still a few problematic patches (one I just finished getting merged / ready to verify & test it)....

So as soon as I can get through these few problematic patches, I will probably post a build.... All around, it should be better and the branch is 10x easier to work with for me now.... (*Really easy to cheery-pick commits from all everywhere, far better organized).

I'll try to get one up tonight, if I get through it....
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Horgar:
Look forward to it.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Colday96:
Do you use Java ? I am currently using C and I would like to know if I can build a rom using C
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Cool. Just working on it. I really want to make sure it's solid... I did have a single camera crash on a previous build ~ so I don't want to push one out until I think it's very unlikely a crash could happen ~ *although* - I've had several updates to Google Camera in the last few days from the Play Store - So I'm wondering if all of these crashes may not actually be my fault (although some are for sure. lol... Well, trying to run EASv1.4 - although, a handful more patches and I should have it all caught up...)...

I Don't really like Java, although I do work on some code that is java, or rather software that I hack on..... The linux kernel is most certainly written in C though...

Android userspace is a combination of langauges, a ton of Java - You _could_ build a a userspace in C - but it wouldn't be android's userspace.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=4932363]Horgar[/MENTION]

May not be up tonight, unless later (for me) like a few hours ~ I'm having difficulty with something, so just trying to step through it + I need to test it a bit... good news is; the camera seems to be much more responsive, bad news still getting the odd random crash - but there are a couple commits to stilll work in ~ the one I'm working on now; should fix the camera crash - requires backporting... so A bit of effort....

the other commit - I'm not sure how to handle yet, might require backporting or the function names and definitions are a bit different. I don't really know yet, as ~ one thing at a time. lol

but if I don't get it up tonight - should be tomorrow.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Horgar:
Just woke up. Don't worry, take your time. Thanks for your work. I'll be keeping an eye out for a new build. It sounds good.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Well, it appears that I'm going to have someone working with my on this now, which is really awesome. So just working on getting that together; putting together repositories, all of the tools and resources needed, etc...

With my current running build - There's still the odd FC/crash with one or two apps (google camera included, although ~ crashes aside it is working much better). The crashes are likely due to some yet to be merged code. All of the EAS stuff is tricky because it touches on a lot of the scheduler code - so one thing excluded or slightly wrong and bad things happen...lol... That said ~ I'm running the current code, regardless of the odd crash and it's shaping up very well; fast, responsive, good battery life.... very stable, excluding the odd case.... I'm also looking at options on how I can enable input boosting (with would improve responsiveness/fluidity)...

But given a bit of time to get the last pieces in place for EASv1.4. things should work out.... Then I can get back to merging in some other commits that I'm sitting on && turn my attention back to the missing kernel function I need for Binder / Binder 4.4 port ~ I just want to get a good stable release out before diving back into that.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
a bit of an update:

I'll have most likely have a new RC test build up later ~ I may have actually resolved the Google Camera FCs.... I just want to run it for the day to make sure. Then I will post a build.... It seems to be tied to some upstream ARM holdings patches that I was using (actually lots of people use them) and/or a patch that I had been using for BRK to do with randomization. It was an upstream linux commit. hmmm....

These never used to cause problems, but it could be that the last build or two of Google Camera, or some change in LTS or in Marlin's monthly patches, etc ~ now it seems to cause a problem.... So rather than fighting with it ~ I'd rather just revert and move forward...

I still have a handful of EASv1.4 patches NOT applied. Two commits I haven't figured out how to deal with... and another causes a boot loop. But all of the 'meat' of EASv1.4 has been merged... seems very stable now that I've reverted the Camera crashes patches...

In other News, after the big refresh of my sources (starting a new branch and reapplying everything + working on EASv1.4), I've also started a branch for Binder again. I've merged in all of the upstream Binder changes, save three; which cannot be applied due to lacking kernel support... Now that Google Camera is no longer crashing - I think I will be testing Binder again - if Google Camera does not crash (at all), Then most likely; we will be getting that code into a test build too, at some point. (which would be nice - it's much faster)....

Anyhoo, I will post a build probably like 5-10hrs from now, assuming Google Camera behaves. (a build without binder changes, just to clarify)...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
zero crashes on Binder updated build ;)

so it appears that the problem is fixed. Definitely have test builds later ~ probably for both branches
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION] => other good news;

- Input boosting will be working in the next build too ~ and has no problems for the (ultra) low latency audio path... I still have to settle on default values to set.

- Maple IO scheduler will also be available - although, I will not really be testing with it, as I'm more focused on

important stuff... and ideally, I would like to have CFQ and deadline in tip top shape... (hint: I do all testing with CFQ io scheduler)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION] => other good news;

- Input boosting will be working in the next build too ~ and has no problems for the (ultra) low latency audio path... I still have to settle on default values to set.

- Maple IO scheduler will also be available - although, I will not really be testing with it, as I'm more focused on important stuff... and ideally, I would like to have CFQ and deadline in tip top shape... (hint: I do all testing with CFQ io scheduler)

EDIT:

if all goes well on the test builds; The build from the branch without the binder changes will be marked stable and replace the OP download...

- the binder build will remain a test build (although it is very stable - it's what I'm using now).