yashsingh1/xdaforums huggingface dataset:
[ONE Original Android Development] abhi08638:
Well since I am currently on his kernel I don't know what features other kernels include. Although I'm trying to keep all the features I have previously seen from other kernels as well.

As for installation, I have two options

-make a new separate flashable zip for UKM

-modify the data/UKM/ folder in the kernel zip and rezip it

The things I have changed are the following

-bacon specific installation

Hotplug

---------------

1. Msm-mpdecision

-downlock duration Max is 5000

-cpu0,cpu4 parameters removed

-time threshold Max is 1000ms

-reorganized hotplug with corresponding unplugs

2. Removed unused hotplugs which are not for our device

I/O

------------------

-readahead from 0 to 4096 with steps of 64

-nr_requests from 64 to 4096 with steps of 64

Gamma

------------------

-remove faux gamma

-remove Franco gamma

Sound

-------------------

-all boosts are from -20 to 20

Wake

--------------------

-remove unused dt2w from other devices

Adv

--------------------

-remove sKSM or uKSM (forgot the name)

-lmk limits moved from 300 to 400

Profile

--------------------

-workaround for the restore profile force close

The fc is caused by synapse trying to edit a read only database. I have had no success modifying the app itself since I am not well versed in smali.

The way the workaround works is when you click apply profile, synapse will reset the uci by deleting and regenerating the config.json file and then killing synapse and restarting the activity.

I was also experimenting with renaming mpdecision as an enable/disabke feature and the renaming function works (from mpdecision-rm to mpdecision and vice versa). The problem is I still don't know how to actually enable it, but it's not really a priority
[ONE Original Android Development] abhi08638:
[MENTION=5438598]RenderBroken[/MENTION] pm'd you the new ukm
[ONE Original Android Development] RenderBroken:
Thanks! I will pull out from it and give credit to you for the Edit.
[ONE Original Android Development] abhi08638:
No problem, ak is going to be merging it into his ak-ukm git soon as well
[ONE Original Android Development] Snuzzo:
Just stopping by to say hello to a good friend and working on something with him. It's pretty nifty that should help him alot behind the scenes. Enjoy the kernel! :)
[ONE Original Android Development] Flak:
AK puts the flashable zip of his latest UKM in his third post.
[ONE Original Android Development] RenderBroken:
Yes, some cool things afoot that should also make it easier to setup your build environment like my own. Tweaking anykernel in the mix as well. Thanks Bro!
[ONE Original Android Development] gauravsaini964:
Hey I want to try your kernel.Will it work with vanir exodus ?
[ONE Original Android Development] RenderBroken:
I am pretty sure it does. Give it a shot and report back. Thanks!
[ONE Original Android Development] Nandeh:
Looks like the fix for battery drain with the new firmware drivers works good...

Someone posted screenshots in the newKernel thread. Maybe you could compile a test build with it. I will be glad to test it :)

Thanks!!!
[ONE Original Android Development] schaggo:
I consider myself heavily plagued by the touchscreen issues. So, to try the yet-experimental new syaptics drivers (the brand new ones, which get loaded per panel and are not even in the cm nightlies yet) I went ahead and flashed ak's kernel. The new driver works as the previously updated one did, with DT2W and gestures enabled I can not make out any additional drain during sleep cycles though, where in theory the previous driver iteration under the same conditions should have produced considerable drain.

I have to stress out though, as a heavy poweruser its difficult for me to notice small variations in battery life, as I manage to run down the device in one day anyway, so the battery percentage usually is falling fast either way ?

What I am pleased to say though, with my typical settings applied to both kernels (same custom gov, hotplug, gov tunables, etc ...) your kernel seems a tiny tad smoother in general operation [MENTION=5438598]RenderBroken[/MENTION]. Again, with my specific settings that is. But either way, I applaud you, well done!
[ONE Original Android Development] RenderBroken:
I will most likely not be doing any test builds with the new firmware setup. It's alot of work and I have sen hit and miss with it. (See below)

Glad to hear! Thanks for reporting. You sealed the deal for me and I will wait till something else comes by and will just do 2 separate builds till we have a definitive fix. Thanks for the concise information as always!
[ONE Original Android Development] schaggo:
I'm back on your kernel, missed the smoothness :p

I always run a build with modified synaptics drivers, for the reasons stated above.

Previously I had DT2W disabled to - if believing in tales and mistery - counter the drainage. I enabled it for my ak testride and I leave it enabled for now to see if the "old" new driver produces any noticeable drain, as the new new one did not.

This will be the first cycle with it enabled. Getting results will take some time.

May I ask by how far the new drivers are a hit and miss? Not that I did deep research, but so far found no posts indicating problems or a non-working setup. They seem to work fine from what I understood by reading and experienced by experiment.
[ONE Original Android Development] Hiro Nakamura:
New synaptics driver has been merged.
[ONE Original Android Development] RenderBroken:
I had seen other reports. I don't ever make decisions from a single point. Well at least with Development. I had seen a couple other reports that said there was little to no improvement concerning actual touch/drainage. Just seemed like a mess that needed to be ironed out first.

I will make a new build today.
[ONE Original Android Development] CorB3n:
Stupid question : on Euphoria with AK Kernel how to switch to your (waiting for new TC fix inside)

Thanks and sorry if question was already posted
[ONE Original Android Development] mp3deviant721:
Dirty flashing the ROM and flashing the kernel on top is the easiest way.

OnePlus One | Powered by EuphoriaOS x RenderKernel

---------- Post added at 03:49 PM ---------- Previous post was at 03:20 PM ----------

I'm having some slight and occasional wakeup lag. Running Interactive/tripndroid/2048 readahead set at the stock clocks and wakeup boost is checked. Any suggestions guys?

OnePlus One | Powered by EuphoriaOS x RenderKernel
[ONE Original Android Development] adinkwok:
I suggest going with smartmax. It works well with many kernels and give amazing performance and battery balance.
[ONE Original Android Development] LiquidSolstice:
I too strongly suggest you stick with Render's defaults. They are pretty damn good already.
[ONE Original Android Development] RenderBroken:
I have noticed something similar when using Interactive as well. Also it only happened once for me but never happened when using SmartMAX, It may be related to some of the new Interactive changes of late. I will look into it.
[ONE Original Android Development] mp3deviant721:
Cool. Awesome. In the meanwhile I'll go back to the defaults and try a clean flash as well. Mahdi just updated Euphoria. [emoji41]

OnePlus One | Powered by EuphoriaOS x RenderKernel
[ONE Original Android Development] HaTrED_:
Just flashed!

Testing it right now under CM12.1 by RobbieL811. ;)
[ONE Original Android Development] adinkwok:
R11 is not booting on the latest EuphoriaOS build (June 2nd) for me. Doesn't get past bootlogo.
[ONE Original Android Development] LiquidSolstice:
Hate to be the bearer of bad news, but the bootlooping has gotten worse for me :(. I flashed it on top of EuphoriaOS (the latest build) and I looped through the OnePlus logo nonstop. The poweroff after flash trick didn't work, so then I had to hold Vol down, get back into recovery, shut the phone off (making sure it wasn't plugged into the wall because it likes to turn itself back on if it's plugged in), and waited 2 minutes. When I turned it on again, it looped twice, and then booted Euphoria properly. When it booted, it worked beautifully, making me fall in love with my phone all over again, so there is that!

However, just now, after setting Euphoria up, I went back to recovery to take a Nandroid, and after that, I ran into the same problem. I just shut it off now through TWRP, and I'm going to try again to see if it repeats the two-loop-then-boot process that it just did. I feel pretty confident in saying that I think the looping issues are getting worse :(

EDIT: Reflashed the kernel, turned the phone off, waited about 3 to 4 minutes. Turned it on, it looped once, and now I'm booting to Euphoria. The rest of the kernel experience is wonderful, and is worth the effort required to get it going, but it's probably worth taking another stab at, and I'd love to help out in any way I can :)
[ONE Original Android Development] misal6666:
can this be used with 5.1.1 android version?
[ONE Original Android Development] 1337jay:
Yes, reading the OP would help :P
[ONE Original Android Development] misal6666:
i did read the op but when i flashed this over cm12.1 it just stuck into continuous bootloop from the bootlogo

any idea what kernel is available for AOSPA (paranoid android)?
[ONE Original Android Development] mp3deviant721:
I dunno what I did different from LiquidSolstice or Qrze, but my flash over the latest Euphoria went fine... Booted up and its working great right now.

OnePlus One | Powered by EuphoriaOS x RenderKernel
[ONE Original Android Development] abhi08638:
[MENTION=5438598]RenderBroken[/MENTION] I'm adding a build prop editor in synapse. I'll pm you with the required files once its finished :D
[ONE Original Android Development] HaTrED_:
Happened exactly same thing to me!

I was able to replicate your issue just like you described above!
[ONE Original Android Development] RenderBroken:
Same here. This issue really drives me nuts. But I do know when it started so I also know what I can revert. I have ben surgical for now but am about to just blow it up and remove everything from R10.

Sweet! Cant wait to check it out!

On another note, I may be rebasing soon as well. Sometimes its nice to do some spring cleaning. I think I have found the fix for a weird reboot that would occur if I did the Load Based Scheduler commits along with other advances Scheduler changes. There would be a lockup when a tread was trying to be waken. It would cause a reboot. I had stumbled across a commit that is similar to one I used but it had a little extra. Literally here it is "s->"

I pointer was not being referenced in a function. So, I plan on doing a test build that will be pretty close to stock and is just a build to show proof that its fixed. Not sure when I will do this test build though. Should be ASAP because if I can get all of that to work, it would really bring in some noticeable performance and battery. Essentially it makes the scheduler aware of frequency and loads and schedules accordingly. Also it makes CPU-Boost work smarter as well. IF the tests go well then I will rebase on top.
[ONE Original Android Development] Gusy_80:
Slimsaber (fusionjack) 06/02:

R11-T5-OldTFW: ok

R11: bootloop.
[ONE Original Android Development] schaggo:
Worse? That's how it always was for me, since the looping started. If it did loop, it looped exactly the way you described: endless reboot after bootlogo. Also when hooked up to the charger. It boots up fine if completely off for a minute or two, unplugged, basically completely left for dead. Then it boots up.

The current R11 did not loop once though, it came up straight from after flashing out of the recovery. I did not even bother to shut the device down. This is on todays CM nightly; CM12.1 03.05.2015 that is.

*correction: I flashed a second time today, the exact same files. This time it looped. Procedure as always, wipe /system, flash rom, kernel and then addons. It boots fine when powered down and left dead for a while.

Reading this, a question just popped up in my mind which I have been asking myself for a couple days already. Maybe you can give a more or less generally applicable answer:

I found that many "modern" governors have a touch boost function. Smartmax does, Intellimm does , zzmoove also, as does slim etc. Your kernel offers a dedicated touch boost functionality though which I imagine collides with the governors boost logic. Having for example set different timers for the two logics, boosts happen longer than the one or the other logic expects, thus screwing with the governor, trying to ramp down already but being blocked by the boost functionality. Or setting different freqs I imagine also screws the governor, over as it tries to ramp down where the boost functionality plugs two cores at relatively high speed, out of the blue, "for no reason".

How would one as a user go about that? Prefer the dedicated boost and turn off the governors logic? If yes, how would one do that? Or turn off boost functionality and use the governors input boost logic? Which one is sleaker, neater, quicker, with less overhead? Could you recommend something? Or use them in a staged setup, high freq short time boost, followed by lower freq longer time boost, before releasing boost alltogether?

Last question: is the touch boost functionality you provide with your kernel technically part of the hotplugging system or are these completely different things?
[ONE Original Android Development] SanXacobe:
On Slimsaber as well and no issues with R11 after dirty flashing rom before installation. Did you flash over R11-T5? Clean flash?
[ONE Original Android Development] Norapapa:
Euphoria Form 02.06 bootloop with R11
[ONE Original Android Development] RenderBroken:
I would recommend using CPU-Boost over the built in boost functionality. The way CPU-Boost works is by bumping up the min freq. This makes it so it doesn't cause issues with the governor and makes it universal. In that the governor will then make calculations based on the new min freq, but then when the boost is gone its making calculations based on the old min freq. There are others that use "Touch Boost" and it essentially still ties into the CPU-Boost driver (Or one just like it) but it gives boost "hints" that tie into the governor to make it do something differently when there is boosting that is going on. I personally don't see the need for this when I can just control the min freq through CPU-Boost and not make the governor's job any more harder. On a side note, this is why some ppl report this as a glitch in Trickstermod and other apps of the like because they are trying to set the min freq but it keeps being bumped up to the "input_boost_freq" value. One thing is for sure, CPU-Boost keeps things very simple yet smarter. With the new changes I have been wanting to bring in, it would work with the scheduler to help queue threads to certain cores.

One thing to keep in mind is lets say you have 2 cores working but then the workload is small enough to then drop a core. Well before it can hand over the workload to another core the new core HAS TO BE at or above the same speed than the core going offline or the core that is transferring workload off of. This is where cpu-boost comes in becasue it boost all the cores and makes them essentially the same speed thus making the transfer of workloads easier. Then when you add Load based Syncs, you make the scheduler work WITH the CPU-Boost driver. Where as they kinda just do their own thing and are unaware of each other. This is just one point where I can make them work better together and get better performance and battery. Also MSM_Hotplug just works well with CPU-Boost but CPU-Boost is not part of the hotplug system, more like a helper.

You always seem to have bootloops. I have the exact same setup with 0 issues. I wonder what you do differently. Can you explain your flash process in detail? Not sure if I had gotten this info fro you before.
[ONE Original Android Development] schaggo:
[MENTION=5438598]RenderBroken[/MENTION] excellent reply, thanks a lot.

How would one disable any "boost" functionality a governor provides? Set the governors boost timer to zero or frequency to zero or simply to lower values than that of CPU-boost?

Now I can make sense of what you wrote a couple weeks/months ago btw. Regarding the whole "boost" business of CPU-boost vs. touch boost. Up until now I figured it's the same thing, it's just the one dev giving it this and the other dev giving it the other name. I did not realize it's two different things.

One las thing, I will give Synapse another go, despite me not liking it. Kernel Adiutor fails with your kernel, max freq gets raised to 2.5GHz all the time ignoring my lower set boundaries etc. It works, but I guess there is no way around Synapse if one wants complete control :(

Darn, yet another thing: that new hotplug, autosmp, is it any good? How is it different from the other three? And in general, which of the three would you recommend? From my rather limited perspective, Intelliplug seems overly complicated and difficult to asses (it might be the über-hotplug, but still is difficult to setup for the average noob like me), msm hotplug seems to work ok but I still find it rather option-heavy :p and msm mpdecision seems neat and tidy but I found it's plugging to be rather random with the settings I have/had. Autosmp has no settings at all, hence I ask...

Taking your answer into consideration, I guess msm hotplug is the one to use together with CPU-boost...? Btw, which one is that famous bricked hotplug, would that be msm mpdecision? Never can tell them appart...
[ONE Original Android Development] RenderBroken:
There is usually an option to enable or disable boost with a 1 or 0 withing the governor's sysfs. Also all hotplug essentially do the same thing. It's how they do it that makes them different. In my humble opinion, msm_hotplug is the best out of all of them. No one should judge something overly complicated based on the number of options. All hotplug essentially have a large number of functionality. The main option differences from mpdecision and msm_hotplug is that msm_hotplug gives you the ability to change options while mpdecision chooses not to give you any ability to change options. I also choose msm_hotplug because if you were to look at their source files, you will see the msm_hotplugs code is smaller and cleaner (in my opinion) than the other hotplug out. It's logic seems to be the simplest and gives you the right options for hotplugging. Also they make the most sense. You want two cores online all the time? Then just set min cpus to 2, you want it so two cores are always online when you touch the screen then set boosted cpus to 2. You want it so when there is a large load spike for all cores to be online? Adjust the fast lane load to the load amount that you want to trigger this event. Also msm_hotplug will online the core that makes the most sense unlike other hotplug that go in order. It's really fascinating.
[ONE Original Android Development] Norapapa:
I have clean flash the euphoria Rom with slim zero gapps and dpi 360. After Boot system i restore my apps with titanium backup. Boot recovery and flash R11 + ukm 3.8.1.4 and have a bootloop
[ONE Original Android Development] schaggo:
I did not mean to insult or offend anyone, I simply tried to paint my words with images. I tend to and like to do that :p

So as I said, the one or the other hotplug or governor might be the über-thing there is and is pure art, this might or might not be the case, I can't judge. What I meant with having too many options to chose from: if you have 20 variables to play around with for the governor and another 15 with the hotplug, and they interconnect, you might never ever reach the result you wanted to simply because it's all way too complex.

As for MPDecision all other hotplugs, the difference there is clear. I was asking about AutoSMP though, the new kid on the block in your kernel, developed by mrg666.
[ONE Original Android Development] RenderBroken:
I wasn't insulted the slightest. Usually when I write, I do so with everyone in mind. I like to wrote like someone actually reads this thread to learn. Autosmp has tunable as well, for some reason they are not shown in kernel adiutor. I don't know too much about them. Lastly, the governor and hotplug are pretty independent from each other. You can make changes to the governor settings and they will not really dictate the hotplug. The only thing they really share is they both consider load. If the governor can handle load faster than that lowers the need/chance that the hotplug needs to enable another core.
[ONE Original Android Development] abhi08638:
[MENTION=5438598]RenderBroken[/MENTION] this is probably what the end result is gonna look like. Do you have any suggestions?
[ONE Original Android Development] RenderBroken:
K thanks!

Looks good. I would like to test it to see what each button does or looks like. But I think it looks great.

New Test Builds!!

R12-T2

R12-T3

They both have some changes so those of you that have bootloops really easily, I would love for you to try on then the other. They are essentially R11 with some minor changes/reverts. These two should show me the culprit.

Thanks guys for your patience and help!
[ONE Original Android Development] abhi08638:
Pm'd you two zips. One is flashable and the other is the code
[ONE Original Android Development] Norapapa:
Great Job render . R12T3 and euphoria no bootloop
[ONE Original Android Development] mp3deviant721:
[MENTION=5438598]RenderBroken[/MENTION] Would you consider a governor request?

OnePlus One | Powered by EuphoriaOS x RenderKernel
[ONE Original Android Development] HaTrED_:
Well, in my case things went a little bit different:

R12-T2, flashed, booted from recovery without any issue. Rebooted again to recovery, booted from there, no issues!

R12-T3, flashed, booted from recovery, got 1 boot loop once and them it booted fine! Rebooted again to recovery, booted from there and it booted just right!

Tried again R12-T2's previous procedure with exactly same results! Haven't had time to retest R12-T3!

So, for now, R2-T12 seems to be the right choice which goes against Norapapa´s opinion! :D

Both tests were made under Euphoria-OS-1.1
[ONE Original Android Development] RenderBroken:
Also I want to note that I listen to Music/Audio Books all the time and I noticed Sound is jacked a bit. One thing I did was raise the "Suspend Max Frequency" Under the MSM Limiter Title to about 1.7GHz and that seems to have alleviated the issue substantially for me. Also note that I listen over Bluetooth headphones.

So because of this in R2, I will raise the default Freq to 1.7GHz. Just wanted to see if anyone else wanted to try and report. Thanks guys!
[ONE Original Android Development] RenderBroken:
New Test Build!

The main thing I wanted to test here is I have manually updated Franco's Sound Control. Its adds Headset Gain Control and optimizes a bit of the code. The only off putting thing about it is the Commits I based this off of is older than the original one Franco used for the OPO. So I am not sure why he was use something else for the OPO but hopefully he will respond to my PM. We shall see. Also Bricked HP added back in now that the reboots have been fixed.

I checked Touch Boost and the code is already close to what I use except he modded Conservative Gov to use an extern from touch boost for boosting freq when certain conditions are met. So what I am saying is, at the moment, I would need to pretty much redo my governors Franco style to benefit from Touch Boost. With that, I don't plan on doing it, at least not in the near future. I said I would look and let y'all know.

https://drive.google.com/file/d/0B-GVJKBx9-GncXdpLWdXcVFsSjA/view?usp=sharing
[ONE Original Android Development] störte:
Will try with Darkobas
[ONE Original Android Development] DerRomtester:
You pushed your source to git ?
[ONE Original Android Development] RenderBroken:
Not yet, I usually just push when I release but I will push more often. I will push it now.

EDIT: Push to github