yashsingh1/xdaforums huggingface dataset:
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Haggster66:
dude, please keep it that way.

There's already an abundance of choice when it comes to kernels compiled with -O4, gcc-10_secret-prelease, |ultra pwr V8 toolchain| and the likes. Not to mention kernels that have *both*, zram and uksm activated at the same time...

...so yeah, it's nice if there'll be at least one kernel that can be taken seriously; and Moxie is exactly that right now. Keep it up, please :)
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] core_x:
Do you know how many of the changes are aplicable for our device?
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
I did a study on mainline updates (which I can see you read): http://xdaforums.com/showpost.php?p=69005948&postcount=23

Generally speaking we'd expect a similar trend of about 15% of the code to actually apply to our device, although I don't make it a habit to actually scrutinise the mainline patch sets as closely as I did in that post.

It's interesting to note that the linux kernel has about 15 million lines of code. When I updated from 3.18.20 to 3.18.42 in my analysis there were about 30,000 lines of code changed, which is about 0.2% of the total available code. With only 15% of the patches applying to our device this equates to about 0.03% of the kernel's code being changed in a way that would impact our device.

That being said however, it only takes a mistake in one line of code to completely ruin the kernel. Usually though the mainline updates provide additional safety-checks to help prevent crashes. Here's a good example that highlights the issues of maintaining the kernel quite well: https://github.com/bedalus/oneplus3kernel/commit/0752437d30e58d99148e45714f154f956784622c

This commit is from the 3.18.43 patch set, and is a revert. It's function is to undo something that was committed to the kernel code earlier. The message explains the situation:

So what happened here? The developer made some changes to help catch errors, only for 'Ben' to step in and tell him that his code makes some faulty assumptions about the data it checks, and in any case, the additional safety check isn't required because this code can only ever be run by a specific device.

The majority of patches are like this. They fix things in bits of code that our device will never use. But sometimes there will be a fix in patch B that would help our device, but can only work if patch A is committed, even if patch A affects code that our device doesn't touch. Kernel maintainers just apply all the patches to ensure parity with the mainline.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Hi guys, I've done some pretty aggressive hacking and removed ethernet support amongst other bits and bobs, and managed to strip about 1 MB off the kernel image. Testing version for obvious reasons: here
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
[MENTION=6295391]bedalus[/MENTION] Have you checked this conversation already? http://xdaforums.com/oneplus-3/development/kernel-t3404970/post69226184
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] puschkin:
Working on cb 3.5.4.... YESS. :good:
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Haggster66:
great to see those quick updates.

Btw, I have just checked the stable and the testing branches and both still seem to be affected by the Dirty Cow.

I don't know if it applies cleanly to 3.18, but anyway, for reference: https://lkml.org/lkml/diff/2016/10/19/860/1 (I strongly assume there must be some repo that has the official 3.18 patch queued up)
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] AlkaliV2:
I'll assume you mean it installed on the CB 3.5.4 after you flashed the 3.2.6 firmware first?
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] puschkin:
I flashed the 3.2.7 firmware first yes.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
I have to try and stick to one base for development, so I'm sticking with the 3.2.7 version for now. But it's interesting that this works on CB. I wouldn't have expected that. Although it might be due to the upstream config commits I pulled in.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] AlkaliV2:
I think that is the best move. They already said they are just implementing features from the community build into the stable OygenOS builds, so since your efforts are to offer a solid stock kernel compiling for OOS makes the most sense.

I was just asking him about the method to further my own learning of how it works and to understand how help people when things go wrong.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Stroky:
Seems like the pixel sources a quit interesting. Maybe some good patches for our oneplus :)
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Thanks for the heads-up.

There's no official 3.18 patch, probably one will be incoming in the mainline updates. In the meantime I've backported the fix myself. Other devs are welcome to use the patch if they like: here
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
Been running this test version since you published it. Haven't had any problems so far.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] taha198:
Usually i don't comment on xda and just read the threads. Threads have almost all the information i need without commenting but this thread has bunch of useful information which is not found elsewhere. Discussion in this thread is knowledgeable, interaction is delightful and and upto the point. Hats off to OP for providing such info and maintaining the thread. Though thread visibility is low, but content of thread is high. Keep up the good work.

PS. In post 92, its Movie v4 instead of moxie due to autocorrect. [emoji4]
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
:D Good spot, sorted now. Nice one brother.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Another testing one. Be aware this resets ro.adb.secure to 1 in the default.prop if it has been reset to anything else by any other kernel/ROM default.

I've managed to get the file down to <9MB due to removing obsolete kernel modules.

TESTERS ONLY PLEASE! https://mega.nz/#!O0UHERiC!YkfLehlo7DC5F2vmJF69fCYVQ7sNjE6DE6F1hwXmS2Y

Edit: it resets to 1 (i.e. on).
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Stroky:
Short nooby question. What is the benefit from lowering the kernel size? Does it make the kernel faster or more efficient? I mean yes I know keep the kernel as clean as possible is the best way.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
No, it just makes the download faster in this case. I've cleaned some old clutter out of the kernel zip that shouldn't have been there since the 2nd version (oops!). It wasn't doing any harm, just taking up space.

Disabling unused features just prevents unnecessary code from running. Space savings here are just a fortunate by-product.

This testing version is mainly to test that adb is unaffected by the default.prop mod.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] AlkaliV2:
I'll let bedalus answer you from a developer standpoint, but I can answer as a linux user who compiled linux kernels for awhile (gentoo makes me feel like I'm bad at computers).

I'd argue the top three reasons for a smaller kernel are:

1.) Removes unnecessary modules from attempting to load

2.) Takes up less room on /boot partition for multi-boot kernels (Linux allows multiple kernels)

3.) If compressed, it takes less time to unpack and boot smaller images

Number 1 is what we are most concerned about because the way the kernel works is that you either compile support for hardware directly into a kernel, or the hardware is scanned on boot and the appropriate modules are loaded after the scan completes. That said, some things cannot be left as modules (like boot drive hardware support) because at least some hardware must be functional for the scan to begin. So for example:

I have a flash drive in my device running EXT4 as the filesystem

-I can compile Ext4 into my kernel directly so it doesn't scan for it; it just assumes we needed it and starts it

-I can leave it as an activated module so that the system will check my filesystem and activate the module on boot

-I can turn off the module and remove calls for it in the kernel and my system won't mount

tl;dr is you can compile a kernel with only the needed hardware for you device to allow for faster decompression and booting or you can leave a bunch of stuff in there that your boot-up manager can scan through to see what is needed for your system to boot. bedalus is just making our device use less CPU cycles by not having to read through unneeded lines of kernel code. Thanks bedalus :good:

This is a good article if you'd like to read more: https://www.linux.com/learn/recompile-your-kernel-perfect-fit
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
Hey [MENTION=6295391]bedalus[/MENTION], have you noticed this?

http://www.xda-developers.com/sulta...otloader-check-on-latest-cm13-builds-for-op3/
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Sultan busting out some more very useful mods. We're lucky to have such an insightful dev supporting the device!

Just been trawling through his repo: https://github.com/sultanxda/android_kernel_oneplus_msm8996/commits/cm-13.0-sultan

...and there's some great new stuff in there. I'll check it out tomorrow!
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
[MENTION=6295391]bedalus[/MENTION] I read some more of your findings back in nexus days. About power consumption on different freqs that use same voltage.

Now, with Elementalx kernel you can overclock cpus. The voltage is the same with oc freq and stock max freq.

The question is, does the oc freq use more power compared to stock max?
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] AlkaliV2:
bedalus did the real world testing so I'd be interested to see what real world measurements were on the device. I can tell you from a physics standpoint that it will definitely consume more power.

The theoretical reasoning behind it:

power = voltage x current

With overclocking

you're increasing the current by raising the clock frequency

while leaving the voltage the same. So for example:

5V x 5A = 25W raising just the current 5V x 6A = 30 Watts; You still use more power overclocking (not as drastic as my 5 watt example) with or without voltage increase.

For the longest time I thought that increases in overclock without raising the voltage was a good thing; free speed! But in reality it is a balance between the components not being starved for voltage and being able to perform their tasks. The reason they have you test by overclocking without a voltage increase first is because it reduces heat output and shows that your components perform better than manufactured spec. Once you find their instability point you can increase voltage to ensure that the components get the push they need to complete their binary tasks. So sadly, there is no such thing as free power/speed, just manufactured components that run better than their spec'd counterparts.

Post number 3 here explains it well: https://forums.anandtech.com/threads/does-gpu-overclock-with-no-voltage-bump-increase-watt-usage.2296100/
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Thanks for taking the time to write this and keeping the quality ratio in the thread high.

So... A Gentoo user ay? You must be a glutton for punishment! I had a Gentoo install on this laptop, but try as I might I could not get the display to work right after wake-from-sleep.

I'm currently using Bash for Windows, on which Git seems to run pretty slow, but it's saved me the minor effort of downloading a distro. Pragmatism! (Laziness!)
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Stroky:
Wow thanks for the answers.

Pretty cool to hear the technical stuff from you guys!

Heard about that patch Franco used in his latest kernel from the pixel phones.

Something also interesting for our phone?
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
The battery drain tests I did were on a Nexus S and I made a whole set of measurements for the various power consuming features. They're still up in the spreadsheet here: http://goo.gl/nB35b

From the original battery thread:

...but you also have to consider that the screen uses about 4 times as much power as the processor.

Also, while there are likely to be some parallels between the Nexus S and any other similar ARM CPU/OLED screen device, the measurements will be different. I'd expect both the CPU and screen to be more power efficient, but the CPU probably more so. However, the CPU has higher frequencies available to use, so could actually net more power usage when under high demand. Also, the screen is larger, so will use more power!

I haven't gotten around to this yet, but a couple of things on my to-do list are to evaluate the frequency usage and see if there are any ways I can get indistinguishable performance but at lower frequencies; and to limit the charge cycle to 90% to help ensure the longevity of the battery component. (I'd make this feature accessible via a sysfs switch because I know some people will not be interested in that).
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Yep definitely. I'm going to incorporate that patch today (and have a look at some of the other good work from [MENTION=4800121]Sultanxda[/MENTION]).

EDIT: Guys, what do you think about this one: https://github.com/sultanxda/androi...mmit/3188b6cf6708c23fa22004d7a5bc586d9213514d

I haven't done much photography with the flash on, so I could use some more knowledgeable feedback please :)

EDIT 2: Okay, without the camera flash patch, https://mega.nz/#!r802wJyQ!AADrvA0_QBcpd2oan8wYcRdK50hz94OXHNAITxJBe3Y can someone with root test android pay?
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
I don't know how the camera patches work on OOS since those are applied to sultanxda's CM rom, and the cameras are different. Here's some background stated by sultanxda

"Pick your poison. The good post-process algorithms are only available when the camera is used in HAL3 mode (camera2 API), which is what the default camera app in my ROM uses. Denoise, sharpening, etc. are total garbage with official CM because it uses the camera in HAL1 mode (camera1 API) by default. The camera HAL in my ROM has nothing to do with denoise; the only reason why I compiled a custom camera HAL was to make touch-to-focus work in HAL3 mode (since OnePlus' camera HAL doesn't allow touch-to-focus in HAL3 mode through the standard way).

OxygenOS runs the camera in HAL3 mode. All of the fancy camera features in OxygenOS are tucked away into the OnePlus camera app and OxygenOS' proprietary libraries, so custom ROMs can't interface with the camera in the same way that OxygenOS can. That means I can't use the stuff that OxygenOS is using to achieve good quality photos.

So what should I do? Send post-process quality to hell by using HAL1 mode? Or make the overall camera experience suck by using HAL3 mode? Honestly, both of these options suck and I'm very frustrated by this whole mess.

Also, stock CM and OOS are over-sharpening photos (bad halo effect + excessive noise), so I reduced the sharpness to a more natural level in the 10/16 build."
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Thanks very much Antsu, I'll leave our camera alone!
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
Hi, I tried clean install on stock oos 3.2.7, without root. Test didn't pass on SafetyNet Helper app.

Could someone other test also, if I did something wrong?

Maybe I'll try Sultanxdas rom and kernel, if there's something going on with safetynet, eg does it pass....
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
I've never used android pay so I've no idea what criteria has to be met to work, but there might be other stuff beyond the bootloader locker/unlocked status being passed as a flag on the command line. Cyanogenmod presumably allows these other criteria to be met (despite root) because they control the whole kernel/ROM. Sultan's bootloader hack may not be the only thing required.

If it can't work I'll remove the tweak.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
Yeah, I dont't need that either, thought if there are some users after that, but if not, better remove. I experienced also some problems after flashing, I had to flash v4 before the actual test kernel to boot up properly. Indeed there must be something other also behind the scenes, between cm and oos.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
http://xdaforums.com/oneplus-3/development/kernel-elementalx-op3-0-01-t3404879/page222

Flar2 has implemented the bootloader patch into his oos kernel. Maybe check his repo for changes.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
It's a single commit, it's the same one sultan wrote, it's already built in the test version. If it's not working there must be other differences outside of the kernel code.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Have any other root users tested if android pay is working using the test version above?

If it's not working with Moxie version, but is working on Elemental then it means I've disabled something in the config that is required.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Stroky:
Sorry I can't test this because I also don't use Android pay.

But I really like to see the feature for the battery limiter to 90%.

I do it every time when I charge my phone. But I have to look every few minutes for it :)
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
As it happens I devoted some time to this yesterday.

I got to a point. I've found what appears to be a line in the code that works as an adjustable threshold, but when I tested it at 90%, the phone continued to charge.

https://github.com/bedalus/oneplus3...ede7241bdb6a368/drivers/power/qpnp-fg.c#L2142

It's the line linked above. I'm probably going to need some support from more experienced devs to get this working. I'll ask around.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
Hi [MENTION=6295391]bedalus[/MENTION]. About bootloader patch... I tried elementalx with the same setup, than with your latest test kernel, when trying safetynet helper app. Result; it also didn't pass it, so the problem could be on my side, maybe the encryption has something to do with it.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Thanks for testing. I've reverted it for now. There must be other requirements outside the kernel hack.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Okay, I pm'd a bunch of kernel devs in the forum. LB was the first to take an interest: http://xdaforums.com/oneplus-3/development/kernel-boeffla-kernel-xx-09-2016-t3455460/page28

...but it looks like we're talking about applying a hack that might not accomplish what is intended because modern batteries are better designed:

[MENTION=3946657]xanthrax[/MENTION] posted a very useful link over in LB's thread. (Here's a relevant link from that site: http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries)

I'll continue to investigate however. I've put a lot of time into this section of code so I'm not about to give up!

EDIT: According to the information on the site, there's plenty of evidence to suggest that there are ways to improve the longevity of the battery. The two facts that jump out to me are

Worryingly:

So this topic may in fact be a lot deeper and more thorny than I originally envisaged.

If anyone can source any official word on how fast-charging affects battery ageing please let me know :)
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Stroky:
What do you think about the zen scheduler?

I did a few test a while ago on the elementalx kernel.

The results with discomark.

Zen was every time faster in terms of app opening speed than cfq.

Would be interesting to hear a few words from you guys about that.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
I think the dash charger solution has some benefits over basic fast charge. Check this http://www.phonearena.com/news/How-it-works-Dash-Charge-fast-charging-on-the-OnePlus-3_id82646

Now, if the high charging voltage effects negatively to battery age, according to article [MENTION=6295391]bedalus[/MENTION] linked, then the dash charging solution is quite well developed (assuming it works as described), as it uses high current instead of raising voltage. And it lowers the current when the battery level raises.

I didn't google, if there are some researches conserning high current charging and battery age, but it looks promising for me at least.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Antsu:
http://www.androidauthority.com/vooc-fast-charging-686000/

As the oppo being owner of the oneplus, this is the same charging solution as dash. There's some test results also.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] Haggster66:
I hope Moxie stays clear of any un- or semi-maintained out of tree schedulers. If say, Zen gets added, then the next guy will want his favorite one. And after that one got added, the next ten people will want their own current scheduler of the day. There are quite some kernels with which one suddenly gets a drop down menu containing a list of 10 different schedulers when using a kernel tuner app... it'd be great if Moxie chooses not to be part of those.

Thinking further, I wonder how long it would take until the first one says "why are there additional schedulers but only the stock governor? We would really need governor X here because kernels Y and Z are shipping that one as well."

Anyway... I digress. Regarding faster app opening times... I've just checked and apps open *really* fast on my OP3 running CFS. How's Zen's peformance while updating an app in the background or having a fast download running or both?
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
I'm open to new technologies, but only if they prove themselves. For example, I was an early proponent of SLUB (which is now default) through thorough testing: http://xdaforums.com/nexus-s/general/ref-memory-allocator-benchmark-t1696284.

I've tested CFQ / BFQ / NOOP / SIO / VR / ROW and Deadline extensively in the past. CFQ was always a clear winner. I've never tested ZEN but from the literature I've read I'm not enthusiastic enough to use up time doing the necessary testing (it can be very time consuming to do it properly).

I like to keep my kernel lean and simple. I don't like loads of useless options. I just see them as unnecessary bloat.

I'm happy for people to post suggestions in the thread, but remember that this is just a personal project that I'm sharing, so be prepared to hear a 'no'.
[OnePlus 3 ROMs, Kernels, Recoveries, & Other Devel] bedalus:
Okay, after spending a few more hours reading the battery code, I've identified this code: https://github.com/bedalus/oneplus3kernel/blob/testing/drivers/power/qpnp-smbcharger.c#L9016

...as where I believe the voltages are calibrated for the battery and charger. I'm not yet certain what to do with them, but I'll have a play and experiment with the effect it has on my own device. This is not something I'll be releasing even in test versions until I've done extensive testing on my own device.

According to the website linked earlier: http://batteryuniversity.com/learn/article/how_to_prolong_lithium_based_batteries

v	cyc	%	^
4.3	400	100%	400
4.2	800	86%	688
4	1600	72%	1152
3.9	3200	58%	1856

The table above shows the reduction in voltage and the corresponding reduction in usable capacity, but the increase in longevity measured in battery cycles. Under the ^ symbol is the available capacity multiplied by the number of cycles, giving the total useful work the battery could perform in its lifetime. At the lowest charging voltage, you'd get the longest total lifetime, but the battery might not last long enough to get you through the day since you'd only be starting at 58%.

Anyway, this is all academic until I play with the code and do some measurements.