yashsingh1/xdaforums huggingface dataset:
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION]

Next release will have Notification LED control v1.1c (Boeffla), ported to Marlin - It only needed a few chenges to get working... It adds fade, intensity and speed controls to the leds-qpnp driver....

those LED settings show up in EXKM - but to actually control led notifications, you will likely need an app like Lightflow that allows adjusting LED controls... No Rom support - since google didn't bake the support in....I'm still testing this, but yeah - it works...

Also, got another patch into Binder and also a fix into the Binder-rt branch....

Working on a few other bits too (mostly bug fixes, not new features - the Notification LED control was just a happy accident - I saw the patch - it only took a second to fix up to apply to Marlin ~ so we get it. lol
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Nope. none of that will work - you've hard-bricked your Pixel.

AFAIK. your only option is to try and have the device replaced. you CANNOT lock the bootloader when you are using custom kernels, rooting, etc... There is no way around this that I know of ~ You should've never locked it in the first place, if you didn't fully understand what locking the bootloader does.

Because you have locked the bootloader;

-> running "fastboot oem unlock" probably/shouldn't won't work at all (go ahead and try though).

-> You can't flash anything (like stock firmware) to the device....

-> Verified-boot/dm-verity is now enabled; custom kernels dm-verity key do not match the stock kernel and/or what the bootloader expects to see ~ it will *refuse* to run...

-> no access to adb or any of that jazz either....

You are going to have to talk to Google or whomever you purchased the device from - feel free to NOT tell them what you did to your device.... You should be able get a replacement.... If you still are not getting what we've already explained to you (and yeah, I know what I'm talking about, unless something has changed very recently. - I'd love to be proven wrong! ... but I highly doubt I'm wrong);

just google "bricked phone locked bootloader" ~ you'll see threads all over XDA, android forums, reddit, etc ~ where people have been in the same boat as you.... You've messed your Pixel up permenantly, AFAIK.

Next time, make sure that you understand what something does - before deciding to mess around. It's a tough lesson to learn - and I really do fell for you, as I once bricked a phone years ago... But there isn't anything that I can do for you and this thread also wouldn't be the place to ask for help ~ it's about running my kernel - not unbricking phones. sorry :(

again, you need to replace your Pixel.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] phaino00:
[MENTION=7810360]nine7nine[/MENTION] I have TWRP installed (zip) and understand it's not possible to install your kernel unless booted directly into twrp.img. Excuse my ignorance, but what is the easiest way to remove TWRP?

Definitely reflashing factory image is something I wish to avoid for now.

BTW, I feel real bad for [MENTION=8055124]Colday96[/MENTION]. Tough lesson!

Thanks for your work and diligent support and updates.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Look on the OP First post, under the section "TWRP REMOVAL": I've listed instructions there. RTFM. lol. ;)

The gist is - you need to take the Nov stock boot image (download link on op), then using fastboot - install it. It will wipe TWRP out of your boot partition.... After that, you can use the fastboot twrp boot.img, here;

https://dl.twrp.me/sailfish/twrp-3.1.1-1-fastboot-sailfish.img ....to flash my kernel.

What you just said has ZERO to do with Coldplay96's issue. Please avoid making such comments. i've already explained his problem, I would prefer that people do not add any confusion, especially if they do not understand the problem.... but here, I will give more clarification;

First off, I re-flash the factory images every month (I just remove the flag that wipes data from the flash-all script). I don't do OTA updates, at all ~ full factory image downloaded from google.... IMPORTANT: ***Locking the bootloader and flashing the factory image are two *completely* different things.****

-> A bootloader is responsible for booting, doing a verity of system checks and verified boot, etc... Your bootloader is updated every time you update to the stock firmware... Think BIOS, Coreboot or UEFI on x86 PCs.

-> Factory images contain all of the software for your pixel; vendor images, boot.img, radio firmware, system images, bootloader, etc...

Coldplay96's problem stems from locking his bootloader when running non-stock kernel, software, etc - You CANNOT do that. Which I've already explained... he no longer has access to flashing, adb or any of that jazz and the bootloader won't boot the kernel because the verified-boot/dm-verity check will fail.

anyway, not trying to give you crap - more just trying to educate you (and anyone else reading this). I would also prefer that this topic gets dropped ~ as it has nothing to do with my kernel and is entirely off-topic for this thread.

thanks man :)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION] I may have updated kernels later on.

Probably not a big rush for anyone to switch over, but;

updated to linux-3.18.83.

Notification LED controls

a fix in the binder/binder_rt branches

a commit in the binder_rt branch

I may try to roll in another couple of commits, before pushing updates... For most people; you probably don't need to update, but regardless - the links will be updated...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
The RT branch is excellent, I love the idea of led control.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] phaino00:
Wait one second. The 'reflash factory image' had nothing to do with colday96's issue. It referred to an alternative solution to my question. However, the solution you point out, i.e., the one missed in your OP due to my laziness, seems more efficient.

Thank you.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
I know: the Binder_RT branch is killer.

I thought it might be unstable, have too much overhead, battery drain, etc. It was largely an experiment...lol ... I think I mentioned google trying rt_mutexes before ~ I never saw their implementation, but using the Binder that I've ported with ti's fine grain-locking and making sure that Ion, Ashmem, etc all use RT-Mutexes ~ It really seems to work very well.

- no crashes/FCs (I've yet to bump into one).

- Performance is great

- Battery life is great - 0% drain on screen off, it says 5hrs 15min SOT in Accubattery, but I got about 6 1/2 hrs of SOT yesterday (albeit I'm not a gamer - but do watch lots of videos, use music making apps, etc.. and ran some benchmarks too)....

For me, it's definitely my preferred build. just awesome.... On the subject of benchmarking; I was comparing memory latency between builds (among other differences).... binder_rt branch has much lower memory latency;

Binder:

single-threaded memory latency; 489 ns

multi-threaded memory latency; 274 ns

binder_rt:

single-threaded memory latency; 171 ns

multi-threaded memory latency; 159 ns

It's just one example of where using rt_mutexes seems to really level things out.... But of course, the user facing stuff is more obvious; better interactivity, responsiveness - better scheduling of buffers (makes a difference with audio, which is very noticeable)...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Please drop this topic. You are confusing yourself. Just Never lock your bootloader when using non-stock kernels, software, etc. That's all you need to do to avoid his circumstance....

It was NEVER offered as an alternate solution to your question. You only need the stock boot image (which yes, is in the stock firmware for Nov), but that has nothing to do with locked bootloaders....

Do NOT bring up this topic again - as I already advised you not to do!

It has nothing to do with this thread and I'm starting to get irritated with it. If you still don't understand - go do your own research, read up on android bootloaders, firmware and all of that stuff - those kinds of questions do NOT belong here.

Please and thank you
[Google Pixel ROMs, Kernels, Recoveries, & Other De] phaino00:
Learn to read....and stop the inaccurate judgments.

Dropped.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yup. dropped and don't bother commenting here anymore. you bring way too much noise to the thread and are too lazy to even follow basic instructions... bye.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Horgar:
Used your 3.18.82 binder build now for 13 "hours after a full charge and have 60% battery. Just a normal days use. That's ok. Not fantastic but pretty good. Battery takes a few charges to assess anyway, but so far so good. And it's fast with no issues that I can see. So all good so far.

Thanks
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Cool. that seems reasonable. I do tend to bias performance slightly. In a couple of ways - So i don't expect it too have THE best battery life... Although, I am looking for ways to improve battery life

Background:

I disable: CONFIG_RCU_FAST_NO_HZ

Stock has this enabled. But I am more concerned with the synchronize_rcu() calls and grace periods. So this config is a no go on my kernel....

But I am sitting on some patches that may improve energy efficiency, just not ready to merge them yet.

Glad to hear the binder build is working well. It should be very stable. more so than I initially thought.

feel free to give the Binder_rt build a spin at some point too, if interested (at some point, no rush / need or anything).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
UPDATED: All Builds are updated on OP download links.

The Binder RT build can be found along side the other builds now. I've also updated the feature list to include distinctions between features on the binder/binder_rt builds...

Changes:

- Linux-3.18.83 lts

- leds-qpnp: Notification LED control - V1.1c - Adapted for Marlin

- A fix to the qcom-cpufreq driver (could reduce lag after deep sleep - which I never noticed. lol)

- fix to cfq (to not assume ioprio class has been initialized)

Each build's kernel now identifies which build it is. Like so;

Stable Branch: 3.18.83-exNoShadez-v1.0sb -> sb = (Stock Binder)

Binder Branch: 3.18.83-exNoShadez-v1.0ab -> ab = (AOSP Binder)

Binder-rt Branch: 3.18.83-exNoShadez-v1.0b-rt -> b-rt = (Binder_RT)

This just keeps everything clean and identifiable....

*There is also a change to the binder_rt branch ~ I've replace ion_page_pool with rt_mutexes. However, this may prove to be better as a mutex, rather than rt_mutex. It's kind of an experiment; [MENTION=5502224]siheals[/MENTION] .... Let me know if you experience any audio buffer underruns (in your games, under high load).... thanks!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] Horgar:
Done exactly that. Getting on for 10pm in London so will have a bit of a play now and then charge overnight and see how it goes tomorrow.

Thanks again
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
awesome. I am semi-pushing the binder-rt build a bit, as I'd like it to get more testing && at this point, it does seem to have some advantages over the other builds...

so getting more testers/people willing to try it out is good... especially since it's a fork / slightly different implementation of binder...

maybe with enough testing and a few tweaks, it could end up being my default binder implementation... (?)...

it's a distinct possibly, if it proves to be stable for everyone.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
whenever I get around to the next builds;

I think I'm going to pull back in some of the scheduler/locking changes that I had previously been using on the old sources.... only a small subset, but there is a feature in linux-4.0 that I would like to pick up...

I may also have a couple of sysctl tweaks to add to my init rc... the ones I'm looking at may improve performance slightly (negliable to battery) and also improve audio slightly. not quality - but QoS. ...

I'm going to run this build overnight with my sysctl tweaks and see how it works out.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
so I went ahead and pulled in just the locking changes (and bugfixes) into the binder_rt branch to support a kernel configuration affecting spinlock behavior from linux-4.0...

running it now, probably until tomorrow sometime. next build will probably include these changes in the binder_rt... not sure that I will Push it into the other branches... maybe the binder branch...

I've got some other patchwork I'm testing too... hopefully a small set of commits that might help battery life a smudge. we'll see
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
I have been running binder-rt build for several hours,and find that it's way more snappy than other build and none FCs happen.Thanks 979!You are the best!
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
thanks man... glad it's working for you. there shouldn't be any FCs related to my kernel anymore; I fixed that... had to do with a particular commit / bit of code that is gone now...

what build were u using stable?. ...or the binder build?

yup, binder_rt is way snappier, for sure... it'll probably become my default implementation of binder, eventually. I've been extremely happy with it, surprised and impressed with how well it's working...

I'm working on some optimizations for the binder and binder_rt branches... my pixel is testing a chunk of them now; I re-merged in locking, scheduling code to linux-4.0. I've cherry-picked some optimizations, as well...

my current build is faster (and probably more efficient) than the binder_rt build that I released yesterday... so I expect that there is still lots of room for improvement...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] siheals:
Well I have been testing the RT branch kernel. No locks, no stuttering, 3d games play well with no sound problems at all. Even playing music with them is good. Scrolling through pages on the screen is smooth. I even tried taking lots of camera shots the switching to a game, coped with everything I threw at it.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
good. so my change to the last build didn't affect you, then.

yup. I haven't anything lock, crash or any problems like that....I think my binder/binder_rt branches are pretty stable. I haven't had any bad reports or problems.

hopefully, it stays that way as I get my current set of changes ready && some of the code I plan on trickling in... it should though...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
I am using this build exNoShadez_eas_3.18.83_Binder_RT_32b978b.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Yeah , I know that.... That's not what I asked;

you said that it was much faster than "the other build" ~ I was curious which build you were running BEFORE binder_rt?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=1007992]everyone[/MENTION]

So in the next day or so: I will be publishing a new Binder-rt build, as that branch diverges from "stable" and may also start to diverge slightly from the Binder branch, as well.... Most kernel changes for Binder_RT will make it back into the Binder branch - but any testing and development will happen on the Binder_RT branch first, so those builds will tend show up first.

The Binder_RT branch is already a number of commits ahead of the other branches, so there will be things to test. Just ironing out some more optimizations and giving it a good test run.... But yeah, substantial enough changes that I will want other people to test it out - when I'm ready for that.

Also, Bluetooth starts up much quicker on my latest build, as an aside. lol
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Another bit of news:

It would seem that something either in user-space or in the /vendor partition (probably something in /vendor) is overwriting a setting of mine - probably causing slightly higher battery drain. Interesting. hmmm.... ~ I'm going to see if I can figure out at what point this is happening (in the init / boot up) and hook my setting AFTER it does it's change....

I've also made some improvements to the workqueue subsystem - merging in some upstream code. A few pieces had to be adapted / changed around in a few spots for our Kernel - but it's all working nicely....

Another change - that I meant to make a while ago;

background tasks/apps and system-background tasks will be excluded from using the Big Cluster.... This will allow only the top-app and foreground tasks to utilize the Big cluster (well, all four cores actually). *This will improve scheduling of aforementioned tasks/app groups... we don't want background tasks executing on the big cluster, at all.

So the next update for the kernels will have some nice added bits in there for sure (Binder_rt, more so)... But many of the changes can be picked up by all branches. just a few bits stay in Binder_RT branch.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
BINDER_RT TEST BUILD:

https://github.com/nine7nine/Apps/raw/master/exNoShadez_eas_3.18.83_Binder_RT_49a0e4e_TEST.zip

(not updated on the OP, this is a test build, for those interested in participating)

Changes:

-> re-integrated Locking changes up to linux-4.0

-> re-integrated Scheduler changes up to linux-4.0

-> reworked and integrated Workqueue changes upto Linux-4.2

-> An optimization to mm/slub

-> improvements to the deadline io scheduler

-> sysctl tweak to adjust RCU stall timeouts (applied in init rc / on boot)

-> init rc clean ups (just housekeeping, doesn't affect you).

-> Disallow background/background system task/app groups from using Big Cluster Cores.

NOTE: This build may reboot your phone 1-2 times on the very first boot, after flashing the kernel... Subsequent reboots will not do that... This is somewhat expected behaviour (for now), nothing to be overly alarmed about. There are reasons for this, too many details to explain here, but it won't happen in subsequent builds/releases...

***the only thing that I am unsure of is how that would affect SuperSU installation, since it warns you to not reboot, after install => but someone else can test SuperSu - I'm not installing SuperSU on my system to find out; I use Magisk... If it does cause issue with SuperSU, you can let me know... Then your options would be;

Stick with the Current Binder_rt release - or let the test build above boot once, successfully... then reboot and apply SuperSU.... Again, this should only be a temporary workaround/thing, as I'm still in the process of upgrading a bunch of code ~ I just need to get some good testing in between merges to avoid regressions and introduce instability.... It's a process.

So.... I do have a bunch more changes queued up for the RT branch, but I won't be merging them or rather; posting a build including them for 24hours, at least AND I need to test this build more ~ as I've only been running it for about 12hours. (minus just re-flashing with the init rc changes (that I already had applied in EXKM manually) before uploading the test build).

After this work it done, I can bring the majority of changes into the Binder Branch (If I haven't decided to kill it off in favour of Binder_RT - which is something that I'm seriously considering doing, just as an FYI).
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
*Just as a note: If you aren't into dogfooding test kernels - Don't feel that you need to participate or anything. It is very helpful, but ultimately ~ if I end up having to run these test builds myself for a few extra days - I'm fine with that too - no pressure ;)
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
Both Stable and binder build.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
ah. thanks for the clarification. I didn't realize u tested all three builds - that's very helpful. I REALLY appreciate it...

so did u notice much of a difference between stable & binder build too?. .. just curious about any observations that u may have had...???

binder_rt IS expected to be much faster, since it uses rt_mutexes, benefits from using priority inheritance, etc.

amazing how much influence Binder has over Android, eh?. ... I mean, it is the center of android in a lot of ways - but it impacts performance, scheduling, etc in very testable, verifiable ways... definitely one of the bottlenecks on the platform, for sure...

edit; anyway, the new test rt build is a bit faster too...

also, the coming changes that I'm getting ready to test/merge, I do expect will have some additional benefits/gains... but I'll need to finish up with the current test build, before I can switch over to that next phase..
[Google Pixel ROMs, Kernels, Recoveries, & Other De] almightysiman:
From what I experience,The binder-rt build has less micro shutter and seem more responsive under the same setting,The battery life is almost the same,and just as stable as binder and stable build,I mostly using my phone for browsing and video.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
micro stutter = jitter

Jitter is the proper terminology for what you are describing, yes - that is very much one intended goal of my modifications to Binder(_rt). Reducing jitter also helps with analysis, as you end up getting more consistent results... responsiveness is definitely another goal. I have certain software synths, samplers, etc - where without Binder_rt input feels laggy, too much latency - with Binder_rt, it's VERY responsive, it makes some of these instruments go from unplayable to precise response - very usable.

My observations are pretty much the same. Any difference in battery life is marginal (and well worth the gains). I also agree on Stability. But because my changes aren't used upstream and mostly exist in Academia type projects, and/or proprietary versions of Android... => That is why I marked the non-binder build as "Stable"....

But in Reality ~ all of the builds are turning out to be quite stable and the Binder_RT build is much better than the others... you wouldn't see as much difference, given your typical usage ~ but in the areas that I am interested in and some of the apps that I use - The differences between stock or my "Stable build" VS. Binder_RT are staggering - and that's not an understatement or being egotistical on my part.... Just an observable fact.
[Google Pixel ROMs, Kernels, Recoveries, & Other De] グリッチ:
Been running stable ever since release and all has been well, not a single fc and smooth as always. But I have been unable to pass safetynet check on latest magisk since the first day I installed this kernel. Is anyone else experiencing that?
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
Interesting. Well, I was running magisk 14.3 - but just upgraded now - after reading your message.

SafetyNet passes fine here.... Regardless, the kernel in this case isn't responsible. that base has been covered. So there's something else at work;

Maybe you have a third-party app that is tripping safetynet that you haven't accounted for in suhide????

I'm not sure what your issue is; but I used Android Pay all of the time. Works fine.

EDIT: MAybe there is something fudged up with your Magisk install??
[Google Pixel ROMs, Kernels, Recoveries, & Other De] :
[MENTION=5930088]グリッチ[/MENTION] and regarding FCs ~ none of the builds have any issues... That problem (with google camera, etc) is long gone.

and "stable" is a misnomer on my part; All of the OP builds are Stable as one another - the Binder/Binder_RT builds are just marked "Beta" because of how new the code is (in particular Binder_RT)...
[Google Pixel ROMs, Kernels, Recoveries, & Other De] グリッチ:
Right, since I am seeking mainly best battery of the three builds I'm just using that one and called it by that name.

You said suhide but I said magisk, I don't think those two are compatible. But my games and whatnot do play fine, it's just that magisk manager itself ouputs false on the check.