yashsingh1/xdaforums huggingface dataset:
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=7890918]boom1982[/MENTION]

r562 doesn't contain the S2S/S2W/timeout fix r563 has. If the functions you need are working on r562, there's virtually no difference between the two.

About Battery Extender mod, maybe battery "durability" would be clearer for non-native english speakers like us. Our Li-ion batteries are degrading at each charge cycle, so by limiting the maximum charge of each of these cycles to a lower value, we're supposedly able to extend the lifetime of the battery. Taking 93% as a base is 7% of a cycle gained, so supposedly 7% more lifetime for the battery, while the effective usage time difference per charge is very small. It's about two months battery lifetime gained per two years (double that at 83%). A lower value should extend it further up to the point where the diminishing returns on aging materials will force you to replace the battery if you want to keep the device longer anyway. Depending on the way you're using your device it can be either great or almost useless, but I feel like a 93% default value is a neat way to extend the device's life while not feeling really limited by the missing 7% energy, regardless of what you'll do with the device in a year or two, or more.
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

Just when I set the value to 93%, the battery was still charging up to 100%)
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=7890918]boom1982[/MENTION]

It can/will still charge up to 100% in three cases :

- If you charged your device while not booted into Android (charging from the recovery or with the device 'turned off' for example);

- If you were already charged higher than 93% when you plugged the tab;

- If your battery calibration has gone yolo and it's reporting different levels than it should;
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

Thanks, for patience and answers :)

Another function appeared - arch_power

As I understood this, reduced power consumption during sleep ...

Do you recommend using this function?
[Nexus 7 (2013) Original Android Development] followmsi:
Hi [MENTION=3847629]Tk-Glitch[/MENTION]

Just did a fresh git rebase with your updates from yesterday. :)

Compiled a new kernel .. all seems to be fine.

Made some others tests and wiped system and boot.

Installed your kernel again - but "my" own compiled version only.

Now it's boot-looping while the "android" boot animation is playing - shortly before the system should come up it's rebooting and start over.

Did some more tests ... It's your installer adding some reuired stuff to the system / boot.img.

Once I install your "pure" installer .. all my "own" compiled versions are working too.

Your installer is preparing the ROM for your kernel ... which is fine.

My previous own-compiled kernel versions were working only because I have installed your "pure" installer before. :)

Tested franco.kernel as well .. I guess I have them all now :)

Only your kernel requires "special" initial config to boot up "normally".

What do you think is breaking the boot process without your "special" config ?

Is there a way to add this into the sources ?

My plan was to use your kernel for the next monthly AOSP relase :)

That's why I am asking ...

Thanks
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=5480152]followmsi[/MENTION]

Everything is in the source already. The folder you're after is the "release" folder in the root of my kernel source. My scripts are doing various things dynamically depending on the user profile, and using the anykernel way of copying existing ramdisk for maximum compatibility between roms and other mods. I can describe the process in a somewhat simple way :

-cleaning up known conflicting files from other kernels.

-reading user profile if any, else using default, then generating init.glitch.rc file with it, and renaming thermald.bin, setting permissions etc.

-copying and extracting current ramdisk, moding fstab if needed, moding init.rc and init.flo.power.rc depending on the profile, injecting init.glitch.rc, busybox, synapse etc.

-repacking, setting command-line, building boot.img, then flashing.

-cleaning up cache.

By the way, using the "glitch" building script in the root of my tree will build both full and pure flashable packages in the release folder. I think it's detailed enough for about anyone to understand how everything works. Just ask if something's unclear or you need more help :)
[Nexus 7 (2013) Original Android Development] followmsi:
Thanks .. I know your scripts are in the sources.

And thanks for the explanation.

For the AOSP ROM I want to use standard AOSP ramdisk. :)

My idea was to setup/configure the required setting for AOSP inside the kernel binary and not inside the ramdisk, system nor data -> to be kernel independent.

Do you think this is possible ?

Are there other configs/parameters which are mandatory to get your kernel fully booting ?

For example if the Synapse service is not available .. can the system still boot correctly ? :)

Thanks for all your help.
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=5480152]followmsi[/MENTION]

Synapse is completely optional, as well as init.d injection. Init.glitch.rc with a default profile, while not breaking boot, will lower general performance if missing, but that's about it (and you could hardcode some kind of personnalized profile in the kernel source as you said). Renaming/stopping thermald is required to prevent the in-kernel driver to collide. Command line options (L2 specificaly) may be required to boot though I wouldn't have thought so. Depending on the rom and its handling of F2FS partitions if you have any, the fstab mods are required to boot, but if the rom has support for it already it's unecessary. I don't see what else could be interfering as is though I'll check if I'm forgetting something asap.
[Nexus 7 (2013) Original Android Development] followmsi:
Yes, I do have data and cache on F2FS .. have enabled F2FS support in all kernel binaries where it was missing.

Booting fine on all kernels ..

You add 'formattable' to fstab ..

Otherwise I have the same fstab settings in the AOSP ramdisk.

Except for system which should stay on ext4.

L2 setting for the kernel command line ?

Of course, If not necessary I would like to prevent hardcoded stuff at all.

Thanks
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=5480152]followmsi[/MENTION]

I'm trying to think about what could cause an issue yet nothing comes to mind right now. Though I've been awake for about 35 hours straight and "thinking" is challenging. I'll come back at you if "the thing" imposes itself to my mind or when I'll be able to concentrate better. Later.
[Nexus 7 (2013) Original Android Development] followmsi:
Pls take your time!

Happy that you are "thinking" anyway .. much appreciated.

If we don't manage to implement your kernel into aosp this month we will manage it next month for sure :)

Next week the new monthly sources will come .. to add the "new" prebuilt zImage into the build tree will be the last step :)

Cheers
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

You greetings from alesaiko.

Here a new touchscreen optimization - https://github.com/alesaiko/breakfast-flo/commit/d660b55e88f1f8563c7bf4e2adee951b2efbd87e

Or one can take the whole "drivers/touchscreen/input/ektf3k." from its kernel

ps This he himself gave, if it can be useful to you

It's just that sometimes the responsiveness of the touchscreen starts to decrease at the corners of the screen, it's noticed not only me. This commit can help
[Nexus 7 (2013) Original Android Development] stewie1350:
Does this kernel comes with s2s and s2w ?

---------- Post added at 05:49 PM ---------- Previous post was at 05:45 PM ----------

Never mind.
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=5746632]stewie1350[/MENTION]

yes

kernel have s2s and s2w
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
New update ;)

14/04/2017 - r564 :

- Synced with latest LineageOS 14.1;

- Corrected HZ reference in touchscreen driver.

Enjoy
[Nexus 7 (2013) Original Android Development] SHABBYLEA:
Thanks TK...?

Working great here...
[Nexus 7 (2013) Original Android Development] coremania:
Are we good for 7.1.2 too????

Edit: we are :good::good::good:
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
Indeed we are :)
[Nexus 7 (2013) Original Android Development] sahilg009:
not working with lineage os or nitrogen os rom won't even boot stuck on google logo
[Nexus 7 (2013) Original Android Development] TheC92:
no problem.
[Nexus 7 (2013) Original Android Development] vbaros:
After updating to the latest build both MPDecision and MSM Hotplug were active. I had to disable MPDecision through Kernel Auditor.
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
Thanks for the report, I'll check for potential changes in the mpdecision service starting mechanism.

It should be working. If you were overclocking, lower your values. If you were undervolting, increase them. If you did flash another kernel before, reflash your rom to restore original ramdisks before flashing Glitch ;)
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

Regular problems with touchscreen continue ...

I can not believe that you did not come across them)
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
Hi [MENTION=5480152]followmsi[/MENTION], sorry for the long delay, I've been kept busy as hell.

If I'm not mistaken, Zen is the notification manager. I don't see any reason for my kernel to interfere with it. Are you using my custom defconfig (defined in glitch script) or the default one for flo (naturally called if trying to build AOSP while swapping flo kernel source for mine as is) ? My tree is made to be built as standalone so I'm starting to think the issue might be related to that.

[MENTION=7890918]boom1982[/MENTION]

Well, that's how known hardware issues are. If you fix it, it has no reason to show up. If you don't, it may or may not get triggered in an unnoticeable to measurable to annoying way, depending on various factors you have nearly zero control over... Until you get it fixed. We can help it by kernel and other software, but not fix it. This is the only way : https://xdaforums.com/nexus-7-2013/general/fix-nexus-7-2013-grounding-issue-t3011140

Just disconnecting/reconnecting the connector and adding a piece of spongy material on top of it (to apply some pressure when the cover is closed back) was enough to fix my device and another one here since, well, late-2013.

Up to you to consider it's worth it or not.

----

r365 is up on Mediafire. XDA servers are unreachable for me right now.

Edit : I still couldn't access the download page (even using a VPN) if I was logged in so I did "hack" my way to the upload page and was able to upload from there. Though it's now fixed (yet still unstable).
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

Hi)

What changes in r565?
[Nexus 7 (2013) Original Android Development] followmsi:
Yes, don't see any reason what ZEN is related here ..

I do use the "Glitch_flo_defconfig" for compiling ..all the time !

Want to have the glitch kernel not any flo_defconfig kernel ;)

This I was asking in the beginning .. special config required for full boot.img version of you kernel ?

Cheers
[Nexus 7 (2013) Original Android Development] nokiagye:
You have to open the tab the back cover and fix it is very easy you can find videos on YouTube

Now my orientation and touch problems Gon..
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
It's in changelogs, post #2 of this thread as always. But right, I didn't post it "in the flow" as I usually do :D

Here it is :

07/05/2017 - r565 :

- Synced with latest LineageOS 14.1;

- Added a simple check for the MPDecision service starting mechanism used by your rom : If it's using the same trigger as LineageOS (init.flo.power.rc), you'll be able to enable/disable the service at will after boot. If it's using a different trigger, the binary will be nuked the old way (renamed to mpdecision_bck) if you're using the in-kernel msm_hotplug driver (effectively preventing you to play with it after boot). It's not a solution that pleases me, but it will fix cases of both hotplug drivers loaded at the same time on non-LOS-based roms, and that's all that counts for now.

The LOS sync contains latest security patches btw.

Yeah, I answered my best at the time. I'll work on this in the next few days to hopefuly find a definitive answer/fix.
[Nexus 7 (2013) Original Android Development] followmsi:
You did help all the time !

Pls do not misunderstand my quick answer this morning. :)

Still hoping for a real solution on this topic ..

In my understanding it has to do with the stuff you do in your official installer .. the additional steps to make the kernel fully working on all ROMs - like on my ROM too - but using the official installer only.

Vice versa - some (required) config or parameters are missing if we use "plain" ramdisk only.

Thanks again for all your help ...

Cheers
[Nexus 7 (2013) Original Android Development] boom1982:
Yet wanted to ask -

Is there a ksm in your kernel?

ex manager shows that it is enable)
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
No worries. My turn to be worried about my answers :D We're both definitely not native english speakers and we may "sound" differently than what we'd like to, I guess.

It most likely has to do with something in the automation chain indeed and it's probably so stupid it's under my nose and I can't see it :laugh:

Yes, ksm is enabled and running at boot time.
[Nexus 7 (2013) Original Android Development] followmsi:
Yes, think so too .. if you don't speak your mother language it may "sounds" different.

Looking forward for your answers ... and for the successful integration of the glitch kernel into AOSP ;)

Cheers
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

When installing, if you set the minimum frequency cpu 594 - Then at boot, it turns into 702...
[Nexus 7 (2013) Original Android Development] coremania:
Any advice to config for battery saving if the device is in standby. I notice a drop about 8% to 10% over night ( 6 to 8 hours). Even with airplane turned on. For snappy performance and streaming i'm usually run ondemand/bfq combination, not much overclocking. Actually i'm on latest los but it's nearly the same on other roms too.
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
I'd say interactive with something like noop io sched, 384 MHz min freq, 128 to 256KB readahead, disable msm_hotplug's "io is busy" setting (MSM_MPDEC might get better standby battery runtime also, but untested), set multicore power saving on aggressive, disable ksm, disable DT2W/S2W or enable power key suspend (and use it :D). Other tweaks would be on the rom side. It's insane how many apps will run in the background and wake your device up these days, even in airplane mode..

Thanks I'll check that.

Edit : It was a typo. Fixed in next update.
[Nexus 7 (2013) Original Android Development] coremania:
I'll test that, thx!!!
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

I do not want to bother you, but there is another oddity..

Now I usually use mpdecision. And when the tablet is loaded or rebooted, the two cores behave very uneasily for a long time, working almost at maximum frequency.

And until several times disabled and enabled mpdecision - Only then they come to norm and in idle time one core starts to work. If this is not done, they will continue to behave in a similar way ...

This happens on aosp roms
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=7890918]boom1982[/MENTION]

Running r565 ?

I'm here to be bothered, so don't fear asking and bothering me :D

Could you please check if msm_mpdecision is the only hotplug driver used ? Also, it's "normal" for some cores to get hammered on restart but they should go back to sleep/low freq after a while so if they are stuck there's an issue for sure. It might have to do with the google services "bug" that's been around for years..

It's hard to stay compatible with every rom when each one is using different ramdisks, hooks and/or blobs! :D
[Nexus 7 (2013) Original Android Development] boom1982:
This was and on other versions of the kernel.

How to check? Switch the plug-in in the application?

Did not quite understand you)

After installing the kernel, I can switch plug-ins in the application and they both can work ..
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=7890918]boom1982[/MENTION]

Sorry if I was unclear.

r565 has some kind of fix for the case where both drivers are used if your rom is not starting msm_mpdecision the same way as LineageOS.

The easiest way to check is by using Synapse as I did add a visual feedback on both hotplug drivers state on the first tab.

You must NEVER use both hotplug drivers at the same time btw as they'll interfere with each other :)
[Nexus 7 (2013) Original Android Development] boom1982:
I understood. After you install the kernel and boot - Only one plug-in is enabled. The second plugin is disabled, this is all right.

How to lure you to the slim rom, for testing? :)
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
Hehe, I'll install it as secondary asap.
[Nexus 7 (2013) Original Android Development] boom1982:
There unbearable settings stock kernel)

mpdecision was initially disabled - it is necessary to include it separately in the application, even after installing the custom kernel.

But when everything is set up, with your kernel - this is the best AOSP :)

ps But the synapse there may not work
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
[MENTION=4146736]xaforib[/MENTION] and Fixed install users

I've uploaded a specific kernel for you. It's currently only available in the mediafire directory. Here are the links :

Glitch-N.flo.r565-FixedInstall-Pure.zip

Glitch-N.flo.r565-FixedInstall-Full.zip

It should work the same way as Timur/flar2 fixed install kernels, but on Glitch r565 base. Please tell me if it's indeed the case or not (I mean, working as intended). Thanks.
[Nexus 7 (2013) Original Android Development] SHABBYLEA:
Just to let you know, 565 working very well on Flo...?

Thanks again for your excellent work...
[Nexus 7 (2013) Original Android Development] sidamos77:
I installed full r565 on my DEB and it works fine.

I am pretty sure, that I switched off Double tap to wake in the Aroma installer. However, after checking later in Synapse, it was switched on.

The other parameters that I changed seem to be as wanted (I lowered max freqs to stock).

BTW: Is it normal, that UCI did not work at first? Had to restart it.
[Nexus 7 (2013) Original Android Development] sidamos77:
LOS 7.1.2 has performance profiles. I have it on default ("balanced"). Does this only affect the LOS kernel or does it also affect the Glitch kernel?
[Nexus 7 (2013) Original Android Development] boom1982:
Will also influence

The work of the core will remain the same, but the CPU frequency will be limited or increased depending on the profile, as on the kernel of los
[Nexus 7 (2013) Original Android Development] TheC92:
When using the camera, it will reboot after freezing with high probability.

The stock kernel is fine.

LOS14.1-170509
[Nexus 7 (2013) Original Android Development] sidamos77:
Thanks! Does anyone know exactly what do various LOS profiles change/do?
[Nexus 7 (2013) Original Android Development] yattodettaman:
[MENTION=3847629]Tk-Glitch[/MENTION]: a question for you...

While compiling your kernel with the Glitch script, so using linaro gcc toolchain, i'm getting several warning while the compiler is building PRIMA drivers. The build process ends without errors.

This also happens to you ?
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
I'll check if the DT2W switch is fine, thanks. About UCI, yes it seems to be normal. The only way I was able to fix it was by using prebuilt profile, limiting versatility for both you (users) and me. So I ended up accepting this "quirk" as the best option for everyone.

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

Since Glitch is now fully based on LOS, what works on LOS kernel works on Glitch. These profiles will most likely affect max CPU freq, limit background processes number, use simpler animations or disable them as well as lower backlight.

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

Quoting myself here from OP as it could be your answer :

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

Yes that's normal. PRIMA drivers are a mess and instead of simply silencing these warnings, I've made the choice to see them, to remind me how messy they are. I'll eventually end up fixing them at some point but it's how they were designed, so nothing critical.
[Nexus 7 (2013) Original Android Development] sidamos77:
Thanks, Tk-Glitch! And another question about your kernel with LOS 14.1: ;)

Although I have WiFi off during standby (location background scan also) and the N7 is in deep sleep 98% - 99% of the time, I still have about 10% battery drain per day in standby.

Can you recommend any kernel setting that could possibly lower that drain? I am coming from a Samsung tablet, which had 1% drain per day.
[Nexus 7 (2013) Original Android Development] boom1982:
[MENTION=3847629]Tk-Glitch[/MENTION]

On today's update Slim beta 0.23 - the kernel finally went crazy)

Probably have to look for another rom..
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
Compromises :D Here was my answer for [MENTION=7213002]coremania[/MENTION] to a carbon copy of your question.

I'll add some teasing : I have an experimental tweak in testing regarding battery drain, especially in standby, that will most likely end up in the next update.

I did install it yesterday, but didn't even boot with it yet. Time is still problematic. I tried it a long while ago and got issues. Since SAOSP had everything I needed, I didn't look back to Slim. Maybe I should have done so. Also, CyanogenMod was a pain in the a** on this device before zwliew took over the maintainer crown and I'm convinced it did hurt our (now small) developers community. Funnily it's getting kinda better now that the device is getting really old (by today's standards), but for how long ?
[Nexus 7 (2013) Original Android Development] matcho13579:
Which Synapse setting might break the camera? Recently I noticed that the camera is not working. Today I tried to reflash kernel and I came to a conclusion: camera is working just after the boot and stops working just after Synapse loads its settings. I'm using improved bus overclock, which is set as default, nothing changed besides undervolting CPU and GPU
[Nexus 7 (2013) Original Android Development] TheC92:
Improved (1.19GHz-4.26GBps) is the same as "ElementalX" setting in Flar2's kernel.

The elementalx kernel is fine.

However, the Improved setting of the Glitch kernel is freezing and rebooting.

+ same problem with stock setting

Stock (1.13GHz-4.26GBps) is the regular, out of the box, non OC setting.
[Nexus 7 (2013) Original Android Development] Tk-Glitch:
Then I'll have to ask you guys about the rom you're using. Camera is flawless here with latest LOS on my two devices, and the only difference regarding camera between Glitch and EleX right now is that I've merged the latest LOS updates (that are not yet merged in EleX).

Edit : So latest LOS for [MENTION=5267239]TheC92[/MENTION] obviously. Not sure for [MENTION=3845051]matcho13579[/MENTION].. That's strange now. GPU OC ?
[Nexus 7 (2013) Original Android Development] TheC92:
LOS14.1-170425 + Glitch-r564 also had the same problem.

So I have been using ElementalX.