yashsingh1/xdaforums huggingface dataset:
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
*lol* Ah, ok. Yeah I forked them back in cm-11 times. There was no lineage back then. "Fork" is no git command, but an github implementation. The pro of forking is just my data plan. If I would have done something like this:

mkdir -p frameworks/base
cd $_
git init
git remote add cm https://github.com/CyanogenMod/android_frameworks_base.git
git remote add nvertigo git@github.com:nvertigo/android_frameworks_base.git
git remote add los https://github.com/LineageOS/android_frameworks_base.git
git fetch cm
git fetch los
git checkout -b cm-14.0 cm/cm-14.0
git checkout -b nlos-14.1 los/cm-14.1
#make some changes, while los/cm-14.1 is changed upstream
git fetch los cm-14.1
git rebase los/cm-14.1 nlos-14.1
git push -uf --all nvertigo

Assuming the repo was empty created freshly on github, I have a branch cm-14.0 based on cyanogens outdated repos; and a branch nlos-14.1 baswd on lineage cm-14.1 branch. There would be no "forked from..." line on github.

It does not make sense to talk of forks at all: I can fork vertex manifest repo, rename it, to android_frameworks_base, and do the very same as above, github will still state it's forked from vertex/android, but the codebase on cm-14.0 and nlos-14.1 are the very same (It's just you carry around the manifest's history within the complete repo's history, with no common commits to cm-14.0 or nlos-14.1 - though the latter repos have common commits (everything, including the last commit on cyanogen). In the end "forked from...." does not mean anything.

I prefer forking in the webinterface, because it safes me from downloading and uploading at least one complete history, whats important for me because costs and quality of my data plan.

BTW: copying the files from an existing repo to a newly initialized repo and commiting with something like "imported files from repo xxx" is not only bad manner, but it completely breaks the history down: it's not only stealing the original authors athorship, but it renders the git unusable (i.e.: try to revert a single previous (and voided) commit).

If I talk of code, I always talking of git itself (nothing else makes sense). When I refer to github and it's webinterface I talk of github. When it comes to github, the main function for me is: it's a repository server. Other then for forking and/or creating gits, I only use github's webinterface for pointing to code lines or commits.

Oh, and sometimes for cherry-picking: if I want to pick a single commit from an other repo without pulling it completely, I cut the commit's URL, append .patch to it, and feed it to "git am".

EDIT: [MENTION=535343]all[/MENTION]: learn git. Never mixup git and github. Always tell git functions from github api!
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
NLOS boot logo

https://github.com/nvertigo/firmware-3t/raw/master/archive/nlos_bootlogo-v0.1.zip

Happy flashing!
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
UPDATE (maintainance release: sync los)

Build 20171009

Releasenotes:

This build requires firmware OpenBeta 15 (aka ob15). As always an archive of all firmwares can be found below in the firmware section of Downloads - the flashable firmwares are the original (file names starting with oxygenos* hold original fw files) OnePlus fw images.

Changelog:

Resync los; no changes in device, kernel or blobs.

back_in_black_bootlogo-v1.0.zip

Camera- and Gallery-Download (If you havn't done so, update com.oneplus.camera and com.oneplus.gallery.)

[SIZE=+2]DOWNLOAD[/SIZE]​

Happy flashing!
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] stevenkyk:
Just switched to this rom a few days back, I have to say I'm really satisfied with this rom, with this being my first eas rom. Though not as feature rich as RR or any other rom, it's stable, smooth and battery friendly at least for me.

I noticed very little about battery life has been shared, so I'm sharing mine here (SOT is meaningless, per hour drain is easier to compare). Idle drain overnight is around 0.5%/hr, that's with WiFi on and 3G network, both at full signal. Active drain is mostly below 10% as long as not gaming/web browsing. Disclaimer: my brightness is mostly on the lower end below 20%, as I'm under shelter most of the time.

Just curious about something, perhaps someone experienced might have the answer, why is the default GPU clock set at 214MHz? Won't it cause more drain than if set at 133MHz? I'm controlling it via /sys/class/kgsl/kgsl-3d0/default_pwrlevel
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
Thanx for your kind words.

Havn't looked at that, because I first want to uncripple our LITTLEs... I guess it's the same root: perfd.

I had tried to find the opcodes in perfd (kanged from marlin) and hexedit them - but failed on finding them (on max_freq LITTLE). :( Sadly our own perfd does not know about eas. Anyway: lowering min freq will save some bat. But how much? I think it's rather feelable. If you want to really save bat, you need to cut down the maxs, like sultan has done on bacon.

If anybody manages to hexedit the kanged perfd (I belive it's in the client lib, but even on that I'm not 100% sure), I would be happy to take it to NLOS.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] stevenkyk:
I wish I knew all of these more in-depth to provide help, by my understand your current aim is to first increase the max frequency of the little cluster, so as to lower the time big cluster is running at high frequencies so as to save juice. And then perhaps to implement the steps in between the 1.6ghz and 2.2ghz?

Also, doesn't the SD 821 have this bug of rebooting when the big cluster runs at 2.35ghz for a while? Sultan lowered the max frequency for this reason, which I personally experienced quite a few times (or was there a fix for this?), then stuck with 2.1ghz until before this rom. Would there be any similar stability issue with the small cluster though?
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
For "in between freqs": far as I could see in OOS the LITTLE 2.2 GHz are only used to boost if renderscript and/or systemui are already running on the LITTLEs. This should be faster and saves the context switches... But I think we are talking about optimizations of 1 - 3 %. As stated previously, I've given up on hexediting perfd's opcodes.

For the 2.35 GHz bug: I could never reproduce this. Neither with NLOS, nor with OOS 3.5.x. I made it a rule fpr myself: deal with the issues at hand, do not deal with issues other roms suffer from or rumors say it should be there. I'm not a heavy gamer, but if I run antutu 5 or six times in a row, I guess there's no thermal or whatever issue with 2.3 GHz.

On the other hand: I havn't run a build for longer then 5 days... So, perhaps... If you know a way to reproduce the 2.3 GHz reboot, let me know and try to get the pstore data after the reboot.

https://android.googlesource.com/ke...android-3.10/Documentation/ABI/testing/pstore
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] joshuous:
I've never experienced the max freq bug before either
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] stevenkyk:
I think a not very elegant workaround for setting the scaling_max_freq. How about setting it to 2.1GHz then just chmod it to prevent further changes? I tried and it sticks for now.

Not sure what is setting the 1.6GHz whenever there is a change in app, I'm not sure if any errors are being logged in the background.

BTW, while browsing init.qcom.power.rc, I found the culprit for the GPU idle, there is a typo.

# Set idle GPU to 133 Mhz

write /sys/class/kgsl/kgsl-3d0/default_pwrlevel 6
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] Dek0y:
Hi all,

Been using the ROM about 2 days now. Noticing high battery drain off a clean flash.

Last night, drained about 2.4% per hour. My CPU times show that my little cluster spent about equal time at min freq and at 1593. This should not be when device is at idle. Has anyone else experienced this issue? Is dev aware/working on fix? I searched and I do see some recent thread chatter about little freq but it's not clear what issue with regard to little cluster is being discussed.

AOSPA had a similar issue and they released a flashable zip for a fix. I have no idea if it's related or if looking at that could help but I just thought I should mention.

Thanks! SS attached.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] stevenkyk:
Not related at all, you might want to use bbs or something similar to monitor what's keeping your phone awake and the cpu running.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] Dek0y:
I'll do that but I don't think I'll find anything. You're suggesting an app is waking only my little cluster and only running it at 1593. Seems unlikely.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
I would like everybody to test the "sysfs ro scaling max" commit. I had this "unelegant, but ****ing effective" idea, too - but it bootlooped rabdomly on one out of five reboots. Where exactly are you doing the a-w?

I gave up on this, when realizing, that perfd (clientlib) changes the maxfreq and the minfreq by purpose on some power hints (voxpopuli). I think that's essential to our eas implementation... ;) But perhaps that bootloop was something other. Let's go ahead:

Testkernel with 0444 on scaling_max_freq is attached as zip. (https://github.com/nvertigo/android...mmit/d036ad688c9d8a4a858ba8706cbb3fa4bd53aa37 - authorship faked to stevenkyk <stevenkyk@xda> - see my note on submitting patches, please.)

This is difficult to understand for me. You seem to think I know what exactly you are assuming, when giving one piece of information.

On submitting patches: the easiest way would be the uri of the commit or a format-patch.

Changing pwrlevel to 7 alone does not change anything. But this works.

This is also implemented in the attached bootimage.

To use the attached boot.zip rename(!!!) it to boot.img and flash it in twrp as image.

BTW: I doubt, it's a typo. It's just another sacrifice on the altar of unified builds. As you can clearly see in this commit, op3 has only 6 pwrlevels and op2 only 5. They optimize for op3, but treat the 7th pwrlevel of op3t as non existend. OnePlus is working around that with init shell scripts, which set this property according to the model used. los abandoned that scripts to introduce the init hackz. But since 3t is only the ugly stepsister, they just cripple it to op3 capabillities... Anyway: I don't want to start this argument again. I added Gibb's rule #217 for me: never ever buy a OnePlus device with a character in it's name, if it comes to open source roms - or your device will always be the last important priority... Sad, but true.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] stevenkyk:
I'm definitely not the person to go to on such matters, but from my limited knowledge, idle drain is mainly affected by a few factors, the signal strength of your wifi & mobile network, frequency of wakelocks, time that your phone is able to enter deep sleep. I'm not suggesting an app that wakes your device, but that is just one of the factors, the limited amount of information you have provided isn't going to help, running bbs is yet one step out of many more possible to get to the root of your problem.

---------- Post added at 01:35 PM ---------- Previous post was at 01:20 PM ----------

I will do a test later, but I doubt this is the proper solution, I found that the frequency still resets to 1.6ghz after a while, haven't been able to reliably pinpoint what changed it, might be due to perfd like what you have mentioned. Some daemon is setting the correct permission after a while I assume, just not sure what and when.

I'm no developer actually, so most of my ideas are tested out in userspace, i.e. through terminal.

I'm more than willing to help and perhaps get my feet dirty in tweaking your code directly, at the moment I have exams to handle, so only pockets of time are available, I'll see what I can help nonetheless.

Regarding the GPU pwr level, i discovered that while using another kernel previously and the dev made the tweak and it worked, subsequently reverted the commit. I didn't understand why until you mentioned about op3. That kernel is unified, so now things make sense to me. Thanks for helping me slowly piece things together and cover the things I don't know.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
*lol*

How do you think I should work on this?

(Hint: logs, bat data, wakelocks, state stats, link to fix, is device sleeping at all)

BTW: If you find system and/or gservices in wakelocks this may also an missbehaving app, but as long as I don't have information this is wild guessing.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] Dek0y:
Here is link to discussion when it was involving AOSPA. On AOSPA it only affected f2fs users but I'm on ext4 on your ROM with the identical issue I had on AOSPA f2fs. The fixed boot.img he provides in the xda linked in the thread fixed the issue. https://redd.it/71yaut

I don't have any logs or anything like that and I've already left your ROM bc of this issue. Sorry I can't provide more info but hopefully this is enough of a thread for you to tug on. If you don't care to look into it further then that's fine by me, like I said I left the ROM, hopefully nobody else is experiencing the issue.

Thanks!
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
Let's make sure, we use the same terms:

I did not change ONE SINGLE CHAR in the kernel!!! I have changed an init script. This might seem niggling to you, but it saves my lifetime, if I have not to search for changes in the wrong git... I already spended nights on serching in the wrong place, because people seem to think "boot.img = kernel", what is just wrong.

initramfs = android rootfs

android rootfs = basic runable system (init (scripts and the init binary itself), healthd, adb, dashd, mount points etc.)

boot.img = kernel + android rootfs

As I pointed out already, our perfd (+perf libs) are taken from marlin (which operates ate exactly the specs we try to fight against) and these do not only use the sysfs interface to comunicate with the kernel, but also send opcodes directly to the eas interface of the kernel (scheduill). Rule of thumb: kernel wins... ;)

We can try to "tune-fake" via the sysfs interface (including permissons), but to change the opcpdes in the kanged closed source perfd(+libs), we need to hexedit them, ask qcom for sources (I'm not sure, if vendors have all parts of these sources, or if they use qcom-prebuild object files to link their vendor/model specific chamges) or remote engineer the perfd(+libs) sources.

I'm not able to do 1 or 3. It's VERY! unlikely, qcom is giving us the sources and I doubt they will be on caf at anytime.

On the other hand: if eas appears for more msm8996 based devices in aosp as well as in caf (no argument if for msm caf and aosp are the same, PLEASE! Not important for my point) it will be implemented by more vendors/models in stock roms - perhaps there will be some more sd821 compatible perfd(+libs) worth to change to... :)

Clean solution? Hmm, I belive I'm guilty of dirty the build by taking marlin's blobs... ;) For a test shot it's surely clean enough.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
I'm on f2fs encrypted to catch exactly all issues (ext4 has none of these) and I'm not expirience your issue.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] mcdachpappe:
previous conversation about stucked frequencies:

i had a smiliar issue like [MENTION=6081049]Dek0y[/MENTION] reported in his first post. i had it quite a few times but i always thought it would be my mistake because no one else was reporting this issue (maybe nobody noticed it - idk). i tried different kernel managers (ex kernel manager, kernel adiutor, ..) to check if its maybe a monitoring issue - but the frequencies were still stuck no matter which app i was using. what i did back then was clearing the cache of those kernel managers, rebooting, wiping cache until the frequencies went back to normal. i never found out the root for this behavior.

note: my /data is formated to f2fs

so i was curious and took a look at the reddit post which [MENTION=6081049]Dek0y[/MENTION] mentioned and found this patched boot.img from arter97 he was talking about (xda post) . next step was to take a look at their sources to find out the commits for this "fix" about stucked frequencys. it seems that only f2fs users were facing this issue. the fixing commit should be this one. in the end i had a look at nvertigo's/los/nlos sources and couldnt find a commit about this "fix". so this kernel could be "affected".

in the meantime i droped eas/vox (you should do this as well nvertigo) from my private builds and tried some different kernel sources without eas/vox support. in my opinion a kernel without eas/vox has at least the same smoothness and responsiveness but with better battery life/idle drain compared to an eas/vox kernel. currently im testing blu-spark kernel (home build) which has the previous mentioned commit merged (and some other commits regarding f2fs which los/nlos does not have). im on day six and i didnt have any stuck frequencies until now. numbers about sot, idle drain, etc. coming soon if you are interested in. i achieved about 3,5 - 4 hours sot in 2 days without charging with pure nlos - which is not that much because im a decent mobile phone user (no social apps except whatsapp and some browsing, even push service for my email app is deactivated, same goes for weather, etc)

tl;dr:

a kernel with f2fs commits runs currently better for me as a kernel without it.

pa kernel source code - arters commits from Sep 24, 2017 could be interesting
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] phenix1441:
I don't have any technical expertise when it comes to anything android, so I can't speak to anything on that level. All that said, I came across this rom looking for something different than all the other unified builds and so far I'm thoroughly enjoying this rom. Fast and stable so far with good battery life. Can't ask for much else.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
NO bat drain issue on f2fs.

I'm intentionally on f2fs with encryption enabled, not because I like f2fs over ext4, but to catch all bugs on f2fs myself, because I've leaned nearly everybody denies to stick to OP regarding logs. That's a point, I really can't understand you: I'm absolutly sure, getting a logcat doesn't hurt.

That being said, I'm NOT expirience this bat drain. I have a idle drain of 0.4% (compared to 0.5 -0.9 on standard los kernel). I have NOT received the requested information. (bat stats, wakelocks, logcat).

Further more: since you have inspected the keenel code, you surely know, what you are asking for: different base, different caf upstrem branch, some commits have such great and useful descriptions like "Merge f7c5dcc on remote branch"...

But even if there would be a single, conflict free commit, why should I merge it? Given the fact, that I don't expirience this myself, and both reporters constantly decline to give an issue report including the information we need to help, I do not see a single reasonable point to change anything.

Nothing of the above is new. Every single point of this posting has been written many times...

I'm pretty sure it's an issue of your (both) installations - and I'm sure we would be able to sort this out with sufficient information.

We have produced nearly 25 KB of senseless, longish, time and bandwith wasting thread, on an issue, that most proppably doesn't exist on this rom, letting me beg for information....

Either provide the information I'm asking for, or stop insisting theres an issue, if you are unwilling to provide information.

After rereading the sensless **** on bat drain, I found this nasty and respectless contradiction:

The latter quote clearly shows, the first quoting is just a lie, and this guy has never ever planed to provide information on wakelocks.

But obviously this conversation encourages at least one other user, to mog about a so called issue...

[MENTION=535343]all[/MENTION]:

No logs (for this matter +bat stats, +wakelock stats) - no issue - no answer from my side. If you need an idiotic, dump OP dealing with your issues, though you are unwilling to provide information: go for an other rom, please. Do not choose vertex, either: I like [MENTION=6745491]joshuous[/MENTION], and he doesn't deserve such treatment... ;) I know this is - by far - the minority, but this minority takes kb of thread and hours of my lifetime.

Bottom line: there is NO bat drain issue on f2fs. There is no reason atm to drop eas.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
min gpu freq / max LITTLE freq

Bad news first: the ro sysfs file does not help. perfd(+libs) is even changing the perms back to 0660.

Good news: the fix for min gpu freqs works great for me.

If I won't receive any fatal reports, the gpu commit will be in the next release - the LITTLE commit will be removed.

[MENTION=4999962]stevenkyk[/MENTION]: would you send me a pm with your alias and email you want to have in the gpu commit, please?
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] :
Just a thought after looking in the aospa patches and the upstream changes in other caf branches: with all that different f2fs patches: has anybody done regression tests against the implementation of f2fstools and kernel of current twrp (or any twrp) and all different patch levels of whatever keenel?

There is an possibillity that if you run implementation of f2fs and f2fstools with patchlevel b on a f2fs generated with with patchlevel a it will work flawlessly and the actual fs is updated accordingly, but if you try now to run something with an older (or just other) patchlevel, you get some issues.

(about 10 or 15 years ago we had exactly this problems with jfs, xfs and reiserfs - zfs still has this issues if you try to downgrade... Normally this is no problem, because you always update, but never downgrade - but with the f2fs patch level chaos.... Who knows...)

Again: I don't use f2fs because I like it, but to catch all f2fs bugs myself, because I'm afraid of getting no logs. I would prefer ext4 encrypted: it's much more evolved, it's much more tested in heavy loaded production systems, and I doubt any real life performance gains (other in benchmarks, but alqays keep in mind, that f2fs is optimized for bms).

I recomment ext4. Again, again, again: I don't usw f2fs because I think it's superior over ext4.
[OnePlus 3T ROMs, Kernels, Recoveries, & Other Deve] joshuous:
If anyone is facing battery drains, you should do the following:

1. Monitor your frequencies using CPU Float.

2. If the frequency is consistently high even when phone is idle, open up a terminal app (e.g. Termux) and run:

su
top -m 10

See if there are any processes that are consuming CPU (ignore surfaceflinger though)

3. And it'll help a lot to show your active drain % if you use ExKM (you should be using it)

4. Also state all the apps that you run that may cause heavy drain

5. Send logcats as well for good measure

6. Report any tweaks done

Developers have a life to live too, and I very well know that [MENTION=4405529]nvertigo67[/MENTION] doesn't have much free time to diagnose vague reports. One of the best ways to appreciate a dev is to submit a thorough bug report