Thermal Daemon Mitigation OFF with CM? - G3 Developer Discussion [Developers Only]

Dear All,
I´ve managed to build a CM 12.1 with nfs support. Why 12.1? Well, for my D855, that was the only branch I could get working when building a kernel in Ubuntu, using the downloadable snapshot at CM´s site. The nighty´s would give me errors of different kinds during the building process, so the files on the phone needed when building are probably not the exact required version that match with the repo you can download in terminal mode.
Anyway, my experience with marshmellow is that the phone gets so hot that it turns itself off - another good reason to stay with 12.1.
My phone however still gets hot, which happens when using it with my VR headset to watch UHD clips. After 5 mins of watching, it dims down a bit. Then a few mins later a bit more, and so on until it looks like I´m staring at the screen through old cheap shades.
I´ve already disabled automatic brightness control, tried apps which claim to keep the brightness at the desired strength (Lux, the app is called), an app that´s ment to keep the screen always on (Always Awake), an app claiming to patch this exact bug, flashed a hack that´ll throttle only above 70 C. None of this helped. What I do know is that in the secret menu of stock firmware, there´s an option called Thermal Daemon Mitigation OFF, but I can´t access the secret menu through CM - only CM´s secret menu, that doesn´t have this option. Enabling this is said to cope with the problem.
There´s also a file named thermanager.xml in system/etc, which looks like something which can be modified to meet my requirements, but I´m not sure.
Finally, my least prefered option is to install a thermal pad on the SoC, but although I´m experienced with hardware, it´s on desktop level - not with such tiny things as a mobile.
So please, could someone help out here? Is there a way to rebuild the kernel with the stock secret menu or amendments to the throttling? Is there a way for me to get into the stock secret menu in CM?
Other ideas?
PS: I´m posting here because if there´s a way to get Thermal Daemon Mitigation OFF option related parameters set when building kernel in menuconfig, then it´s related to this sub forum.
PPS: Edited thermanager so all brightness values are 255, this seems to fix the problem!

Related

Overclocking XDAndroid Rhodium

So I noticed a number of references in one of the mega XDAndroid threads to overclocking Rhodium. Sounded pretty simple, just a string of text with the desired frequency in a particular file.
A couple of questions for those who toyed with that:
1) was it stable and what was its fastest stable speed?
2) did it run uncomfortably hot?
3) is it possible to alter it on the fly (so you can run it slow when you're reading, and crank it up for video), or do you have to choose a speed preboot and reset to change it?
4) If it can't at the moment, be altered on the fly, might it be possible for some program to do that in the future?
5) finally, why is it so easy on adroid? It seems like no2chem has hit a bit of a wall in making his winmo project hum, but the references here made it sound like a pretty basic task.
Part of the reason I'm asking is flash 10.1 is due for android in Q1. The last I read of CPU requirements had them over Rhodium's specs by a lot. Mobile hulu access would be fantastic, and I'm planning to start dual booting this summer, once classes are done. It'd be nice if my TP2 could eek out enough performance for that.
Thanks
You could try adding this to your Startup.txt acpuclock.oc_freq_khz=650000, thats the one i use and its prettty nice, i havent notice any heating up at all.
devilcuban said:
You could try adding this to your Startup.txt acpuclock.oc_freq_khz=650000, thats the one i use and its prettty nice, i havent notice any heating up at all.
Click to expand...
Click to collapse
It does not sleep to death for you when you do this devil? I had to take the OC out of my rebuilds, because once the phone sleeps, it will not wake up.
Yep same here. If I add that line, once it goes to sleep in Android, it doesn't want to wake up again...
Reefermattness said:
It does not sleep to death for you when you do this devil? I had to take the OC out of my rebuilds, because once the phone sleeps, it will not wake up.
Click to expand...
Click to collapse
On the Hero one it does , on you build even tho its not really need it i've been using it for a while and it doesn't do it .
So interisting thing, it does go to sleep of death, the reason it didnt do it before for me its because i've been using with htc_battery_smem.fake=1, but as son as i disable that it went to sleep and didn't get up.
devilcuban said:
On the Hero one it does , on you build even tho its not really need it i've been using it for a while and it doesn't do it .
So interisting thing, it does go to sleep of death, the reason it didnt do it before for me its because i've been using with htc_battery_smem.fake=1, but as son as i disable that it went to sleep and didn't get up.
Click to expand...
Click to collapse
I did test and confirm this. I think what happens is with smem.fake=1 the phone actually never goes to sleep.... at least the sleep light never turns on. I will have to ask phh if this is the case.
Tried putting the overclock line in Startup.txt but it did not seem to change anything, at least according to the CPU Benchmark app. The battery line did seem to work though, as it thought it was charging even while not plugged in.
Is there a specific order that these parameters need to be added in? I just added the overclock line at the end and the battery one after that.
Using the latest non-sense 2.1 builds.
I'd love to add Rhodium overclocking support to my RogueTools application.
I think there is still a constraint though with write access to /system. I am hopeful that shortly the Rhodium kernel and rootfs developers will deviate out of the current read only SQSH model and go the way of the Vogue, Kaiser and Polaris hosting the system and data in separate EXT2 partitions on the SD Card. NAND would be the next step.
If someone knows another way to overclock on the fly once the system is up (post boot). PM me. Like I said, I'd love to add support for the Rhodium.
so nothing on the OC for 2.1 yet?
bump
I'm about to test overclocking with the SetCPU app. Worked fine on my rooted G1. I'll report back with my findings.
Edit: Did not work with custom and/or multiple devices selected. Can't push any higher than the stock 528. Blah.
on screen keyboard
when i put both sleep fixes and the overclocking cpu command in my startup text i get the on screen keyboard like in rhobuntu. how do i disable this? its not even usable it just lingers there and its very annoying
O.S.K. byebye command is msmvkeyb_toggle=off
OverClocking M2CW & IME
Data corruption is inevitable without running extensive stress testing to find a safe speed. I have yet to find one for msm7k processors, but surely Qualcomm has one. Benchmarking is not the same as stress testing. Such stress testing apps need to be run for several hours & even days. They can't test all functionality accuracy. Stress testing in themselves can cause hardware damage & even catastrophic failure.
Data corruption is often the "silent killer" and goes undetected by you or system checks ... until you need it most. It may be a config file, a message file, a contact database, an executable, a registry hive, a system file. Any non ROM file is vulnerable. Backup OFTEN & NOT while OC, even though BUed corrupted data is still corrupted. Quote "stable speed" isn't such just because device doesn't randomly lock up or reboot.
Every CPU and memory chip has different limitations. Same phones built on same date may not OC the same.
Don't OC when when building new Android data.img file, downloading update files or apps, extracting or creating archived files, installing apps, encrypting or decrypting.
OC doesn't help Project XDAndroid developers. I suspect many "bugs" they spend valuable time on are OC related.
The msm7k processors supported by Project XDAndroid are a speed scaling processor designed for optimum performance vs. battery runtime, ramping up and down the processor speed based on demand. Average device use doesn't utilize full processor speed.
OC is most noticeable in OS boot times (when OC is initialized prior to), certain multitasking operations, some video playback, CPU intensive games, & to a lesser extent web browsing. Many factors determine the effectiveness of OC especially whether graphics are hardware or software supported.
Your OC device may actually perform worse, noticeably more sluggish, or more jerky than when not OC. Ever notice on some boots into Android it takes forever for your carrier to be detected & displayed on the lock screen and it may creep along as if your processor was hijacked by a random process? Ever notice when you open the app drawer not all your apps are displayed?
OC does use more energy thereby shortening battery run time and producing more heat. Don't complain about battery life if you are OC. Accurate battery charge state & battery run time are not synonymous.
While OC may shorten hardware lifespan it most likely, though possible, will not lead to a catastrophic failure in the typical device lifetime due to the rate of current technological innovations and average length of ownership.
My overall performance satisfaction with Project XDAndroid is best when not OC, especially now that hardware 3D is supported or partially supported as in my rhod500.
OC at your own risk.

[[Speed Improvements]] Brainstorming & Testing Thread!!

Hey guys,
Seems there's a lot of ways you can improve the speed of Android in general. Some seem to be snakeoil... others, work quite well and there's proof to back it up.
I'm only interested in discussing the latter .
A lot of people have helped me gather a better understanding of Android (hyc, stinebd to name a few) in addition to a lot of Google searching. I am going to compile a list of what I have done, I would like to hear what you guys have done! Most app killer apps / app control will already be addressed, so those tools need not apply... I'm looking for real, permanent fixes here without adding more apps!
I am also trying to have topics that are easy working up to advanced. Obviously the more advanced topics are going to be harder to do. You've been warned.
So here's the disclaimer.
****DISCLAIMER****
Speed is as always relative. That basically means I don't want arguments about which build is faster. I want to argue about how to make every build faster .
Also, these tips should apply to any build, any device... they are pretty generic tips, but are obviously specific to Android, with some idiosyncrasies that apply to our port that wouldn't apply to native Android devices. Some is common sense, others are real ways to tear into the system. Hope you enjoy it!
Topic 1
Difficulty Easy - Apps/Widgets​
I've noticed the number of widgets i have on my screens, or the number of apps that I have installed/are running in the background to greatly effect performance, in an obviously negative way.
Once I removed all the widgets (I only have the basic analog clock widget & the Google search widget on one desktop...) this seemed to improve general speed. One minor thing to check is if apps are set to auto/background sync. Only enable the ones you really want syncing, others just check manually.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
The last thing on this topic I would like to mention is animations. Settings -> Display -> Animation -> No animations can make the phone feel quite a bit snappier, obviously at the expense of the look/feel of the OS.
Topic 2​
Difficulty Easy - Controlling app 'net Access​
This leads me into the next topic, DroidWall. I've noticed that blocking apps from accessing the internet has been a very good thing - it's not so much a performance booster (although it probably does provide a little bump) it's mostly about battery life. Just be warned, if you block an app that is set to background sync, it will probably have very negative effects. Only disable an app's access to the internet with DroidWall after you've checked that app's background sync feature is disabled. I have a few apps allowed in DroidWall, and the rest are blocked. You can "whitelist" everything and check apps you want to block, or "blacklist" everything and check the apps you want to allow. It's a little annoying to remember to enable/disable DroidWall (I use the DroidWall widget to enable/disable it globally) but if you do, it is much better - you have complete control over how apps access the 'net on your device. It is available on the Market.
Topic 3​
Difficulty Moderate - SD cache/readahead tweaking​
The only reason I'm calling this one 'moderate' is the number of choices you have for settings for this... It's basically telling the SD card how much to hold on to or... read "ahead" if you will . This was turned way up in FRX07, (from 256kb to 2048kb or 2mb...) and I think this might be the source of a lot of the complaints of 'mini-resets' if you will where the boot animation is suddenly seen after a long system hang...
So some cards will work better with a larger setting - I've heard some with spankin new C6 cards that said 3072kb or 3mb was a good setting. Others have found a sweet spot at 256kb or 1024kb (1mb).
There are two ways of doing this - you can hack the init in the rootfs and adjust the setting manually, or be lazy like me and use SD Booster (from the Market). Adjusts the same settings, and they are applied immediately!
I would like to find a "sweet spot" - a good default if you will. Can folks test out 512kb and 1024kb, see if you have any more mini-resets within Android or any other slowness, etc... Obviously this isn't a cure-all for the slowness or the mini-resets, what we're looking to do is mitigate the effects. So let's focus on that, thanks!
Topic 4​
Difficulty Moderate - Overclocking​
Overclocking is obviously one relatively easy way to improve the speed of Android. In your startup.txt, add a line
Code:
acpuclock.oc_freq_khz=710400
for example to overclock to 710.4mhz. How did I find this value? I actually put in 714000, but if you look at dmesg near the beginning you'll see "ACPU running at ..." - that's what clock is the actual maximum. It goes in 19.2khz increments.
Feel free to experiment with how high your phone can go, just be warned that the higher you go the potential for failure goes up as well . Phone shouldn't blow up, but it might not work correctly or at all. Rebooting and scaling it back will fix it.
Here's the full *example* startup.txt:
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 acpuclock.oc_freq_khz=710400"
boot
You can put the command anywhere in the cmdline section, just make sure it's between the quotes and at least one space between each command.
Topic 5​
Difficulty Advanced - How Android Manages Memory/apps​
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Topic 6​
Difficulty Advanced - Managing Apps that auto-start on boot​
This is one of the most annoying things in Android. When you have no apps installed, it seems very fast. Then you install apps, and you never seem to get that original speed back... Now you can!
This is kind of difficult to do, I am still getting the hang of it... but here goes. All credit goes to hyc, his original post.
The basic idea here is you run a logcat (adb logcat is easiest here, or you can use GetLogs to pull logcat...) Look in this log for "for broadcast" and find apps that start on boot. For example,
Code:
Line 41: I/ActivityManager( 1394): Start proc nextapp.systempanel for broadcast nextapp.systempanel/.monitorservice.BootReceiver: pid=1752 uid=10060 gids={3003, 1015}
Notice there are two sides of the "for broadcast". The name of the package (nextapp.systempanel) and the name of the service, "nextapp.systempanel/.monitorservice.BootReceive". I made the mistake of disabling the app (the left side). Do not do this, you want to disable the right side!
So in the shell,
Code:
pm disable nextapp.systempanel/.monitorservice.BootReceive
This will be persistent across boots, it will go with your data.img.
Obviously this was just one example of an app to disable. So long as you disable the right side (after the 'for broadcast') you shouldn't disable anything that will cause a serious problem. The apps should still work, but for example if you disable Google Voice you won't get messages until you open the app. So think about that... You disable Titanium Backup schedules.BootReceiver, the schedules for Titanium Backup (if you have any) won't run. Stuff like that. Disable calendar, you won't get calendar events... Disable clock no alarms. Get it? Good. I have been rebooting several times, and I keep checking what is set to start on boot. I'm not quite happy with it yet, but there's some things I'm leery of disabling. Just be wary, if you do disable something and don't like it - just pm enable <whatever you disabled>.
Now experiment away! The one caveat is if you do break something with pm disable (and it's serious) you might get a failure to boot. It really depends on how bad you mess up. If you make a copy of your data.img before you start making these changes, you can revert to that data.img and start back there.
Alright guys. Going to use this thread as a way to brainstorm about ways to improve the speed. Read up what I've posted, let me know if I did anything wrong... Also let me know what you guys do to improve speed!
Don't care about what build you're running, this thread isn't about what build is fastest - this is a how do I make every build faster thread.
I also realize I posted this in the Rhodium section - I want to see if there's any BLAC-specific tweaks that others should be made aware of!
Thanks. Great posting. Will try some of the topics I never used (because I didn't know about them).
ThaiDai said:
Thanks. Great posting. Will try some of the topics I never used (because I didn't know about them).
Click to expand...
Click to collapse
I'm sure there are more as well... These are just the ones that I found made the most difference on my device.
I'm also curious about the minfree setting. I've only tried a few settings, they seem good. I haven't done any drastic number changing, it seems like changing these values should be done with a lot of caution and testing. There are definitely some values that should not be touched and others that can take some more fudging with numbers .
Added Topic 3 and Topic 4 to startup.txt and rootfs.img.
Just booting. Let's see if this is stable.
Software options I do not test now because I only test the new versions now. So specific app optimization only necessary when ThaiDai Android Loader and installation procedure reaches v2
Ok, boot ok, started Android (NeoFROYO build(, will tell tomorrow if stable.
If so I will use this options as standard for Blacky and I will add software like Droid firewall.
Thanks and good night
Update - I redid topic 4, feel free to re-read it.
Thanks
Enviado desde mi FROYO BLUE CWM1.9 usando Tapatalk
Hi Arrrghhh!
Can a squashfsed and odexed apk boost speed inside Android OS?
john_matrix said:
Hi Arrrghhh!
Can a squashfsed and odexed apk boost speed inside Android OS?
Click to expand...
Click to collapse
No clue. What does that have to do with the Speed Improvements thread?
I'm guessing you tried and it didn't work? What APK!?!
I guess I don't really follow your train of thought. Does sqshfs'ing and odexing an APK make it run faster...? I'm pretty new to Android in general. Never even used a native Android device .
http://www.addictivetips.com/mobile/what-is-odex-and-deodex-in-android-complete-guide/
http://forum.xda-developers.com/showthread.php?t=709630
farukb said:
http://www.addictivetips.com/mobile/what-is-odex-and-deodex-in-android-complete-guide/
http://forum.xda-developers.com/showthread.php?t=709630
Click to expand...
Click to collapse
I still don't get what that has to do with our builds. ODEX and DEODEX have nothing to do with our builds... That stuff only applies to native devices, or builds that are ported from native devices (I would think).
Perhaps I'm missing something here... please tell me if I am .
Maybe they mean something else like: oxidized or deoxidized (reduced) apps. With these modified apps you can speed up the transfer of electrons, resulting in more performance without overclocking your cpu. And more: it will not reduce your battery capacity measurable. I used it in some of the builds I tried. You will get a nice small benefit also: because of the electron transfers you will get a small induced massage in your fingers for free.
ThaiDai said:
Maybe they mean something else like: oxidized or deoxidized (reduced) apps. With these modified apps you can speed up the transfer of electrons, resulting in more performance without overclocking your cpu. And more: it will not reduce your battery capacity measurable. I used it in some of the builds I tried. You will get a nice small benefit also: because of the electron transfers you will get a small induced massage in your fingers for free.
Click to expand...
Click to collapse
LOL!
Epic.
OK. I cant get V6 SuperCharger script to work! I downloaded the script and run it but I cant find /data/99SuperCharger.sh after I run it
x12CHRIS18x said:
OK. I cant get V6 SuperCharger script to work! I downloaded the script and run it but I cant find /data/99SuperCharger.sh after I run it
Click to expand...
Click to collapse
Did you make the choices in the script, or did you just exit the script?
You have to make sure ScriptManager is running as root too. There's a setting for it. "Browse as root" - make sure that is enabled. You won't be able to see /data without browsing as root.
...You have a TouchHD? I always thought you had a RHOD, lol.

[Q] Lollipop, The Aggressive App Killer

Does this even need an explanation? Lollipop kills apps like it's his hobby.
Even with only a few light (on RAM) user apps running in the background you sometimes find yourself staring at your launcher home screen that, you could've sworn, was just showing a different app a second ago.
Or the times when, after multi-tasking a bit, your phone starts becoming painfully slow. Turns out that some apps are so stubborn that they go on strike (continuously restarting) when LP kills them.
I'm sure many have experienced this. And I have seen some devs address this issue here and there. I though it would be useful to gather the info into one thread, to ease our (or my?) frustration on this issue.
What I wanna know is, what causes it exactly (why didn't it happen on KK?), and is there a solution to this? Or at some way to calm LP down a bit with his killing of innocent apps.
Thanks.
Djalaal said:
Does this even need an explanation? Lollipop kills apps like it's his hobby.
Even with only a few light (on RAM) user apps running in the background you sometimes find yourself staring at your launcher home screen that, you could've sworn, was just showing a different app a second ago.
Or the times when, after multi-tasking a bit, your phone starts becoming painfully slow. Turns out that some apps are so stubborn that they go on strike (continuously restarting) when LP kills them.
I'm sure many have experienced this. And I have seen some devs address this issue here and there. I though it would be useful to gather the info into one thread, to ease our (or my?) frustration on this issue.
What I wanna know is, what causes it exactly (why didn't it happen on KK?), and is there a solution to this? Or at some way to calm LP down a bit with his killing of innocent apps.
Thanks.
Click to expand...
Click to collapse
Im running 1/8 FML with synapse injected R10 kernel on my toro and with ksm and laptop mode enabled in synapse, I haven't had a launcher redraw in days. I don't have anything whitelisted either. However, the trade-off I have at the moment is I cant seem to stream videos on my stock browser. Havent tried a different browser or anything. I just uncheck those two settings and reboot and all is well, but my phone certainly works much better now, and no redraws, with neph settings for LMK
Hope something helps someone!
Thanks
erk1725 said:
Im running 1/8 FML with synapse injected R10 kernel on my toro and with ksm and laptop mode enabled in synapse, I haven't had a launcher redraw in days. I don't have anything whitelisted either. However, the trade-off I have at the moment is I cant seem to stream videos on my stock browser. Havent tried a different browser or anything. I just uncheck those two settings and reboot and all is well, but my phone certainly works much better now, and no redraws, with neph settings for LMK
Hope something helps someone!
Thanks
Click to expand...
Click to collapse
Perhaps you can noobify that a bit, lol. I had to google almost everything you mentioned. As I understand it, this Synapse allows you to tweak the kernel? And this KSM settings can improve this RAM issue? Care to elaborate? And what is laptop mode?
I've read about adjusting the LMK values to calm LP down a little. Any idea though why this was so necessary in LP, but not in KK? Is stock LP 'naturally' more RAM hungry than KK?
Djalaal said:
Perhaps you can noobify that a bit, lol. I had to google almost everything you mentioned. As I understand it, this Synapse allows you to tweak the kernel? And this KSM settings can improve this RAM issue? Care to elaborate? And what is laptop mode?
I've read about adjusting the LMK values to calm LP down a little. Any idea though why this was so necessary in LP, but not in KK? Is stock LP 'naturally' more RAM hungry than KK?
Click to expand...
Click to collapse
I can try to elaborate little bit, as Ive been flashing things and researching xda a lot, but I am still noob in how/why things are the way they are. From what I gather lollipop just handles memory differently then kk did. I think that is some of the reason as to why the "recent apps" persist through reboots now. Remember, our device was not really supposed to run kk and certainly not meant to run lollipop. The developers here are without a doubt amazing in what they know and what they do for us users. A new kernel and driver was necessary to run lollipop on the aging gnex. Now, some of the issues we are experiencing is a google issue and will only seem to get fixed when they get around to it. I know my nexus 7 (old) has some memory issues and lag and redraws from time to time....not as much as I noticed with my gnex before the changes were made I stated in the above post. I recently helped my friend root and upgrade his oneplus one to lollipop and he has the same issues we all have, maybe not as bad, but they are noticeable
A lot of the questions you have, have been discussed recently in bsmitty83 kernel thread, since I asked them. There are links there as to what KSM and laptop mode are and what they do. KSM-kernel same page merging helps with RAM and I believe laptop mode helps to conserve power. A lot of these things are geared at devices with low ram like the aging gnex, but the developers have done a great job at making lollipop a daily driver. Most users I think use trickstermod from playstore to tune kernel settings, and that is ok, however, you must purchase the paid version to tweak low memory settings, which I did. However, synapse, also found on playstore can also be used to tweak kernel settings, but the kernel has to contain UCI support for the synapse app to work. Synapse has more settings available to tweak than trickster does, like KSM and laptop mode, which have helped me very much. The only kernel I'm aware of that has UCI support for synapse is bsmitty83 Full_Auto R10, because osmosis made it work
Hopefully this was rather accurate and helpful and not convoluted! ha.....im sure some more knowledgeable people will come and correct anything I said that may be incorrect, but in the meantime, read through the R10 kernel thread and see what you come up with
What ROM and kernel are you currently using?
Thank you
erk1725 said:
...
The only kernel I'm aware of that has UCI support for synapse is bsmitty83 Full_Auto R10, because osmosis made it work.
...
What ROM and kernel are you currently using?
Click to expand...
Click to collapse
I'm currently using AOSP rom (by freshgimmi) and the Full Auto R10 you mentioned. I'll try injecting the new ramdisk now and see how it goes.
I noticed this issue as well for the first several days . However once I installed the new bootanimation from arter97 the issue doesn't occur anymore. Not sure if it's related but all I did was mount /system as rw and copied into the new lollipop boot animation from here: http://forum.xda-developers.com/android/software/arm-arm64-android-5-0-lollipop-t3032247
Djalaal said:
Does this even need an explanation? Lollipop kills apps like it's his hobby.
Even with only a few light (on RAM) user apps running in the background you sometimes find yourself staring at your launcher home screen that, you could've sworn, was just showing a different app a second ago.
Or the times when, after multi-tasking a bit, your phone starts becoming painfully slow. Turns out that some apps are so stubborn that they go on strike (continuously restarting) when LP kills them.
I'm sure many have experienced this. And I have seen some devs address this issue here and there. I though it would be useful to gather the info into one thread, to ease our (or my?) frustration on this issue.
What I wanna know is, what causes it exactly (why didn't it happen on KK?), and is there a solution to this? Or at some way to calm LP down a bit with his killing of innocent apps.
Thanks.
Click to expand...
Click to collapse
SpideyTheMan said:
I noticed this issue as well for the first several days . However once I installed the new bootanimation from arter97 the issue doesn't occur anymore. Not sure if it's related but all I did was mount /system as rw and copied into the new lollipop boot animation from here: http://forum.xda-developers.com/android/software/arm-arm64-android-5-0-lollipop-t3032247
Click to expand...
Click to collapse
I know about this issue. It is a memory leak during boot. It is a good catch, though all you're changing is the bootanimation.zip. AFAIK, it should not affect your system's performance after boot, once your phone is up and running. My issue is a different thing entirely. I never got bootloops (that is, when not messing around with xposed).
Okay, you're right. As a test last night I switched from FML 5.0.2 to LiquidSmooth's LP ROM and I'm not seeing any aggressive app kills in LiquidSmooth.
Djalaal said:
I know about this issue. It is a memory leak during boot. It is a good catch, though all you're changing is the bootanimation.zip. AFAIK, it should not affect your system's performance after boot, once your phone is up and running. My issue is a different thing entirely. I never got bootloops (that is, when not messing around with xposed).
Click to expand...
Click to collapse
erk1725 said:
Im running 1/8 FML with synapse injected R10 kernel on my toro and with ksm and laptop mode enabled in synapse, I haven't had a launcher redraw in days. I don't have anything whitelisted either. However, the trade-off I have at the moment is I cant seem to stream videos on my stock browser. Havent tried a different browser or anything. I just uncheck those two settings and reboot and all is well, but my phone certainly works much better now, and no redraws, with neph settings for LMK
Hope something helps someone!
Thanks
Click to expand...
Click to collapse
I have got synapse up and running. I AM wondering though, what LMK settings are you using? Cause the neph settings I know of tell me to set empty app to 370, but synapse only allows max 320... If you're following different settings, could you link the post for me?
Djalaal said:
I have got synapse up and running. I AM wondering though, what LMK settings are you using? Cause the neph settings I know of tell me to set empty app to 370, but synapse only allows max 320... If you're following different settings, could you link the post for me?
Click to expand...
Click to collapse
Glad you got everything up and running.....Im using Neph's settings for LMK, and your correct the empty app only goes up to 320 in synapse. There was a post somewhere where Neph said he was still tweaking his LMK values and I believe he mentioned about lower empty app to 330 or something, so I just set it to 320 in synapse and call it a day

Making G3 work with nfs and cifs

Dear All,
I´ve been researching this subject, and found a couple of threads pointing me in the right direction. In particular this post about mounting cifs on LG G2 was useful:
http://forum.xda-developers.com/showpost.php?p=49291439&postcount=29
I did the following:
I found an Ubuntu 12.04 image and ran it in my vmware, got latest NDK and the Marshmallow Kernel from LG´s website. For the defconfig, there are plenty of configs for G3 so I chose a random and rather small one (1 kb instead of the others that are typically around 20 kb) and followed the steps. When I came to the .config screen I did not find any option to enable cifs or nfs support, so I did the whole thing over again for G2 - just to see if that´d give me the option although I wouldn´t be able to use it for the G3. I found a Jellybean kernel on Lgs website for G2, assuming that´s what was used back in 2013 when that thread was started, and NDK 8d which was the current version back then. I found a small config file there as well for the defconfig, and got into the menu again. Other options it seems, but still none for cifs and nfs. I then tried to add some config lines into the defconfig for nfs, which I found by googling but with the same result.
Should the kernel have some support for nfs in itself, and why would I at least not get it in the menu when trying to do it for G2, like the guy in the other thread managed to do it?
FYI, I love what you can do with ES Explorer and similar apps, but I´m after mounting nfs and cifs - not accessing them via another app.
Hoping for advise - thanks in advance!
Allright, this took me a while but I got it all sorted out!
A brief overview of what I´ve been through:
I found out that I needed a 64-bit Ubuntu, hence got the latest 16.04 and set it up in a VMWare. I tried my best to build my kernel using NDK, but constantly ran into issues with missing files and a whole lot more. I then decided to target cyanogenmod, who has a guide which in detail explains what to do.
The Cyanogen method uses SDK instead of NDK, and requires you to have a branch of Android on your phone already installed, similar to the one you´re building for.
Again I had various issues untill I tried with the 12.1 snapshot (Lollipop), and finally I could build my Rom. I enabled all cifs options under File Systems/Network File systems in the menuconfig, and all with regards to NFS client, except for NFS v4 which also created some problems. You´ll need to have insertion of modules enabled as well from menuconfig.
After that I was able to have mount manager (an old app that you need to google for, market does not have it anymore) do the job. You´ll need to look for dns_resolver.ko and cifs.ko in your android environment under Ubuntu, and put these files on for instance your sdcard on your phone, where you´ll tell Mount Manager that they´re located. They need to be loaded in the same order as they´re mentioned above.
Your mounts are going to show up as files and not folders, if you don´t do the following from a terminal under android:
$ setenforce permissive
NFS I´ve not yet been succesful with, not least because my firewall blocks NFS regardless of whether if I open the right ports, allow all traffic on the hanewin (NFS mounting system) exe files and so on. So at the moment I start looking into getting the job done with NFS, I also need to get another firewall.
Anyway, on this particular Android build, I got a terrible connection speed, but after googling this for a day or two, the fix for me was to change the channel of my 5ghz wifi to 48 on the router. Then it went from 10 mbit to 120 mbit speed!
Still samba(cifs) is slow, which is not what you want with UHD high kbps rate clips, so I´m researching what can be tweaked here.
Anyway, cifs is working, and I thought I´d share this with you so others can learn from it. There´s alot of trial and error I´ve been doing, and if I can save others from having the headaches I had, I´ll be happy
PS: My phone is rooted, but we´re not even at the stage where I´ll be trying it at my phone yet.
PS: Mounting via shell is possible, but I couldn´t get this to work till I installed busybox. Also, for password protected shares, you´ll need to add the unc path.
Example:
busybox mount -o unc=\\\\192.168.178.11\\Movies,user=username,pass=password -t cifs none /storage/sdcard1/cifs/Movies
Doing this in Mount Manager is easy. Do what you would do anyway with setting the remote and local dirs, and add an option with "custom" where for the option name you type "unc" and the value will be "\\\\192.168.178.11\\Movies"
PPS: I figured that you get alot of glitches for VR videos (2880x1440) when using cifs, and I´m on a wifi with 160 Mbps here. I finally made it into getting NFS to work, and that works!
Here´s how:
Make sure you´ve turned root permissions on for adb and apps on the phone and adb into your phone, then:
su
setenforce permissive
insmod sunrpc.ko
insmod lockd.ko
insmod nfs_acl.ko
insmod nfs.ko
For the insmods, you need to point to where they are stored on your phone, obviously.
Now you can (example)
busybox mount -t nfs 192.168.178.11:/VR /storage/sdcard1/mnt/VR -o nfsvers=3,noatime,hard,nolock,rsize=65536,wsize=65536,udp,intr,async,ro
You´ll now have access to VR through /storage/sdcard1/mnt/VR!!
I tried this on both the 5ghz 160 (-200, depending on how close I am to the router) and on a powerline wifi giving me around 35 Mbit speed.
The last one did not work well, so you really need alot of speed.
One thing I struggled with was that I had stuttering after 4-5 minutes getting worse and worse. I found out that in developer options you can switch on awesomeplayer instead of the default one, which solves that problem.
I also found out that D855 (LG G3) is not a 2560x1440 (as it says in the specs) but 3200 x 1600 phone - under the screen settings, you can set the DPI to 640 and it works fine. Yes, this is really true - find a dpi calculator and check it out! I may be mistaken of course, let me know in that case. This gives you almost 39 % more pixel density, so alot more realism!
Have fun, and remember that all the things that are easy to google, setting up ubuntu, finding cyanogenmod stuff, compiling etc is not mentioned here because this is not where you´ll hit your head against the wall. The things I´ve described are those where you really need to be spending time, as the information is rare and device specific since not that many people are dying to connect to an nfs server from android, and even less want to stream UHD clips to the phone
Btw, I´m using the app VRTV since it can be setup to be used with a cheap game pad that I got from aliexpress for EUR 8, so that you don´t need to take off your headset for anything - you can just fast forward, skip to next clip, adjust volume, recalibrate etc. from the game pad.
For headset I´m using one with the highest FOV outthere. It´s the Bobovr Z4, that´s very comfy to wear and even has builtin headphones. I got it for around 25 EUR, also on aliexpress.
If I did not already mention it, I use hanewin under win 10 for nfs server.
One very last thing: Your screen is going to dim after a few minutes, especially when inside a VR headset. This is due to LG´s very ungenerous threshold for when the phone is considered hot, and they´ve decided that the screen should be dimmed to keep it from going too hot. I tried various things.. an app called Lux, another one called Stay Awake, an app solely ment for getting rid of this behavour, and looked for ways to get inside of LG´s own hidden menu where you can get rid of the throttling.
None of it worked - the last two options related to that I´m not using a stockrom here.
Well, I´m happy to use cyanogenmod because the phone is much cooler with that, but since the phone´s so picky with what´s considered hot, it´s still a problem.
I found out that you can edit thermanager.xml in system/etc where you wanna set all values for backlight to 255. Make it look like this:
<control name="backlight">
<mitigation level="off"><value resource="backlight">255</value></mitigation>
<mitigation level="1"><value resource="backlight">255</value></mitigation>
<mitigation level="2"><value resource="backlight">255</value></mitigation>
<mitigation level="3"><value resource="backlight">255</value></mitigation>
<mitigation level="4"><value resource="backlight">255</value></mitigation>
<mitigation level="5"><value resource="backlight">255</value></mitigation>
<mitigation level="6"><value resource="backlight">255</value></mitigation>
<mitigation level="7"><value resource="backlight">255</value></mitigation>
<mitigation level="8"><value resource="backlight">255</value></mitigation>
<mitigation level="9"><value resource="backlight">255</value></mitigation>
And then reboot. I did a test for 20 mins playing a 180/SBS/2880x1440 video, and brightness is still where it should be - at the max!
In my temp monitor, the system temp is 47 C, so that´s fine. Back when I´d be using Marshmellow stock rom, the phone would shut down itself after 15 mins of doing the above at about 57 C.
Now, I cannot guarantee that this, or anything else suggested in this post will not damage your phone. If you want to be 100 % sure of no damages caused by any of this, simply don´t do any of it. IF you do it, it´s your own responsibility. None of this was tested for 3 months on 100000 phones, so I really can´t tell.
G3 is a great choice for a VR experience, since you can get it for EUR 270 - cheaper than any other phone with that resolution. I got mine for EUR 100 second hand, so as an alternative to GearVR, this is a very cheap way of achieving the same.

Research - XZP SHARP Panel @ 120Hz

XZP 120Hz QUEST​
First i would like to push this thread forward cause i thing phone has some potential still to unlock. There is much writen about XZP - 120hz but nothing concrete or usable in stock, before i write something of mine i would like to credit a developer which inspired me to snoof around a bit:
thanks to "kholk @ Github" and here is kholk,s work:
https://github.com/sonyxperiadev/ke...si-panel-somc-synaptics-sharp-4k-cmd-ID6.dtsi
https://forum.xda-developers.com/newthread.php?do=newthread&f=6237
thanks to Paranoid Team for developing a great rom for XZP
http://paranoidandroid.co/downloads/maple
So lots of us have rooted device and in root explorer i triggered search for "SHARP" word just from curiosity, after minutes of waiting search completed and 4 folders stand out:
qcom,mdss_dsi_sharp_4k_dsc_cmd
qcom,mdss_dsi_sharp_4k_dsc_video
qcom,mdss_dual_sharp_1080p_120hz_cmd
qcom,mdss_dsi_sharp_1080p_cmd
Is it possible to enable this mode from this folders and sub files in stock rom? And how would i an amateur user switch this modes?
I will make backups in twrp and then myself try to mess up with files or at least go through them if something punches me in the eye i will report, what i meant to say it would be nice if above links could be used to inject it into our stock roms?
Oh, i recently installed paranoid android and there are settings to enable 120hz but are not yet working, you can google it, so xzp is at least in good hands and path, hope we wount wait too long for this goodies
If annyone has some succes or ideas, observations please write it down maybe some devs will look into them
stipi69 said:
XZP 120Hz QUEST
First i would like to push this thread forward cause i thing phone has some potential still to unlock. There is much writen about XZP - 120hz but nothing concrete or usable in stock, before i write something of mine i would like to credit a developer which inspired me to snoof around a bit:
thanks to "kholk @ Github" and here is kholk,s work:
https://github.com/sonyxperiadev/ke...si-panel-somc-synaptics-sharp-4k-cmd-ID6.dtsi
https://forum.xda-developers.com/newthread.php?do=newthread&f=6237
thanks to Paranoid Team for developing a great rom for XZP
http://paranoidandroid.co/downloads/maple
So lots of us have rooted device and in root explorer i triggered search for "SHARP" word just from curiosity, after minutes of waiting search completed and 4 folders stand out:
qcom,mdss_dsi_sharp_4k_dsc_cmd
qcom,mdss_dsi_sharp_4k_dsc_video
qcom,mdss_dual_sharp_1080p_120hz_cmd
qcom,mdss_dsi_sharp_1080p_cmd
Is it possible to enable this mode from this folders and sub files in stock rom? And how would i an amateur user switch this modes?
I will make backups in twrp and then myself try to mess up with files or at least go through them if something punches me in the eye i will report, what i meant to say it would be nice if above links could be used to inject it into our stock roms?
Oh, i recently installed paranoid android and there are settings to enable 120hz but are not yet working, you can google it, so xzp is at least in good hands and path, hope we wount wait too long for this goodies
If annyone has some succes or ideas, observations please write it down maybe some devs will look into them
Click to expand...
Click to collapse
I wish to have it in Android pie coz of this I really like this phone
I'm building Zest Kernel got this device soon and that surely seems like a great idea. I'm personally thinking of trying to force 120Hz as I forced 90Hz on the Essential phone with celtaire. The only problem is it seems the userland side of things may have limitations to 60fps which would need a bypass somehow, as Razer did.
PA seems interesting that they have a switch so I'll try look at they code to see (if they have the piece of the puzzle I was missing that would be amazing).
Great this would be awesome :fingers-crossed:
can't wait, 60 hz really hurts my eyes.
amakuramio said:
can't wait, 60 hz really hurts my eyes.
Click to expand...
Click to collapse
Lol, as in its pretty smooth anyways. But 120Hz is likely darn water flowing.
Any update on this lol went back to my xz premium
I've been thinking about how to get this working, but it seems tweaking the qcom,mdss-dsi-panel-framerate value on the default configuration (1080p) alone is not enough, although from an initial diff between the original 60Hz configuration and kholk's newly added 120Hz configuration on SonyOpenDevices kernel showed only the framerate value was changed (there are probably things I didn't find).
I've tried changing it from 60 to 90 and 120. Changing to 90 has no apparent effect (the system still renders at 60 FPS), while changing to 120 caused everything to be rendered at 24 FPS (very sluggish). Still, it seems the refresh rate change is indeed set to the value, as this app (which looked rather dated and unreliable) did show the system's refresh rate (rr) is configured to the value written in the dtsi.
From the looks of it, it seems the dtsi file controls what refresh rate be configured at kernel level, but something's probably needed in the userland to get it function properly. But still, it's interesting that setting the value to 120 would cause the system to render everything at 24 FPS, while setting the value to 90 doesn't have any impact.
I posted some details here yesterday as I was mainly building my own CarbonROM zips with some own configurations. For CarbonROM, the dtsi file is located in arch/arm/boot/dts/qcom/dsi-panel-maple.dtsi.
Back to the OP... I've found the entries as well. However, even after I modify the dsi-panel-maple.dtsi and that the modified value is registered somewhere, the value in /sys/firmware/devicetree/base/soc/qcom,[email protected]/qcom,mdss_dsi_sharp_1080p_cmd is still 60 (003c). This file is probably the one representing the original 60Hz command:
https://github.com/CarbonROM/androi.../boot/dts/qcom/dsi-panel-sharp-1080p-cmd.dtsi.
And there's the 120Hz configurations placed in /sys/firmware/devicetree/base/soc/qcom,[email protected]/qcom,mdss_dual_sharp_1080p_120hz_cmd.
This file might be related to it. However, this file is significantly different from the 1080p (60Hz) one and I'm wondering if this is indeed for the same panel our device is using.
https://github.com/CarbonROM/androi...com/dsi-panel-sharp-dualmipi-1080p-120hz.dtsi
Not sure if there are any hope on getting 120Hz working on existing Oreo custom ROMs as SonyOpenDevices is now working on 4.9 kernel (which is used by Pie), and I'm yet to be able to build a working AOSP ROM for it. The last time I built an AOSP Pie ROM and flashed the generated images resulted in a lot of crashes and then the phone powered off by itself... it was completely unusable.
EDIT: It seems the value I previously changed was reflected in /sys/devices/mdss_dsi_panel/change_fps (which can be viewed via cat). As I set it to 90 in the dtsi, the value here is also 90.
raven213 said:
Any update on this lol went back to my xz premium
Click to expand...
Click to collapse
I haven't got round to modding the display on my kernel yet, I'm firstly trying to fix WiFi lol.
---------- Post added at 09:10 PM ---------- Previous post was at 08:56 PM ----------
LSS4181 said:
I've been thinking about how to get this working, but it seems tweaking the qcom,mdss-dsi-panel-framerate value on the default configuration (1080p) alone is not enough, although from an initial diff between the original 60Hz configuration and kholk's newly added 120Hz configuration on SonyOpenDevices kernel showed only the framerate value was changed (there are probably things I didn't find).
I've tried changing it from 60 to 90 and 120. Changing to 90 has no apparent effect (the system still renders at 60 FPS), while changing to 120 caused everything to be rendered at 24 FPS (very sluggish). Still, it seems the refresh rate change is indeed set to the value, as this app (which looked rather dated and unreliable) did show the system's refresh rate (rr) is configured to the value written in the dtsi.
From the looks of it, it seems the dtsi file controls what refresh rate be configured at kernel level, but something's probably needed in the userland to get it function properly. But still, it's interesting that setting the value to 120 would cause the system to render everything at 24 FPS, while setting the value to 90 doesn't have any impact.
I posted some details here yesterday as I was mainly building my own CarbonROM zips with some own configurations. For CarbonROM, the dtsi file is located in arch/arm/boot/dts/qcom/dsi-panel-maple.dtsi.
Back to the OP... I've found the entries as well. However, even after I modify the dsi-panel-maple.dtsi and that the modified value is registered somewhere, the value in /sys/firmware/devicetree/base/soc/qcom,[email protected]/qcom,mdss_dsi_sharp_1080p_cmd is still 60 (003c). This file is probably the one representing the original 60Hz command:
https://github.com/CarbonROM/androi...boot/dts/qcom/dsi-panel-sharp-1080p-cmd.dtsi.
And there's the 120Hz configurations placed in /sys/firmware/devicetree/base/soc/qcom,[email protected]/qcom,mdss_dual_sharp_1080p_120hz_cmd.
This file might be related to it. However, this file is significantly different from the 1080p (60Hz) one and I'm wondering if this is indeed for the same panel our device is using.
https://github.com/CarbonROM/androi...com/dsi-panel-sharp-dualmipi-1080p-120hz.dtsi
Not sure if there are any hope on getting 120Hz working on existing Oreo custom ROMs as SonyOpenDevices is now working on 4.9 kernel (which is used by Pie), and I'm yet to be able to build a working AOSP ROM for it. The last time I built an AOSP Pie ROM and flashed the generated images resulted in a lot of crashes and then the phone powered off by itself... it was completely unusable.
EDIT: It seems the value I previously changed was reflected in /sys/devices/mdss_dsi_panel/change_fps (which can be viewed via cat). As I set it to 90 in the dtsi, the value here is also 90.
Click to expand...
Click to collapse
Okay so I've been looking into this for quite some time and have even got a 90Hz Essential PH-1. But the thing is while we CAN force the display Hz, we aren't telling the display/graphics HAL to run at that frequency. So we need to find a way (or just find the way) to tell HAL to support by default this FPS. Razer clearly does this and that's why even on GSIs the display HAL in its /vendor position loads it up to normal.
Sony's SOMC kernel seems to have the display driver a bit wonky to the AOSP standards as you've seen. It seems this way for their method of HAL switching to 4K. Little OT tip: wm set doesn't change the resolution you see, only changes the resolution that's processed ?.
TL;DR it's pretty obvious (if you spend some time) to see the display references in the kernel where the Hz of the panel is displayed HOWEVER we need to rather focus on finding a way to force/tell the display/graphics HAL to process those 90 or 120 fps otherwise you'll have 60fps on your 120Hz panel .
There is the monitor (Hz) and the processed refresh rate (FPS) and one can usually get used the both being the same when using a desktop system however this is incorrect. They are 99% of the time aligned but it IS possible to have them not aligned (which is what happens when we're changing the kernel here).
LazerL0rd said:
Okay so I've been looking into this for quite some time and have even got a 90Hz Essential PH-1. But the thing is while we CAN force the display Hz, we aren't telling the display/graphics HAL to run at that frequency. So we need to find a way (or just find the way) to tell HAL to support by default this FPS. Razer clearly does this and that's why even on GSIs the display HAL in its /vendor position loads it up to normal.
Sony's SOMC kernel seems to have the display driver a bit wonky to the AOSP standards as you've seen. It seems this way for their method of HAL switching to 4K. Little OT tip: wm set doesn't change the resolution you see, only changes the resolution that's processed .
TL;DR it's pretty obvious (if you spend some time) to see the display references in the kernel where the Hz of the panel is displayed HOWEVER we need to rather focus on finding a way to force/tell the display/graphics HAL to process those 90 or 120 fps otherwise you'll have 60fps on your 120Hz panel .
There is the monitor (Hz) and the processed refresh rate (FPS) and one can usually get used the both being the same when using a desktop system however this is incorrect. They are 99% of the time aligned but it IS possible to have them not aligned (which is what happens when we're changing the kernel here).
Click to expand...
Click to collapse
So it seems we need to also alter the HAL to get the correct FPS. But the interesting phenomenon is, altering the kernel to use 120Hz, without touching any other code, triggers the HAL to render at 24 FPS instead of 60 FPS. This might be a hint on where we need to look at in the HAL code, if possible. I haven't tried other combinations, only 90 and 120, with the former having no impact (60 FPS).
As for you saying the SOMC kernel using a driver wonky to the AOSP standard might explain why it's been so complicated to get DRS (Dynamic Resolution Switching) to actually work despite the functionality's already been implemented in the SonyOpenDevices project (which is NOT what current CarbonROM is based on). Not sure about the functionality in AOSP now, but it's been non-working for quite a while (at least up to the point of switching to the 4.9 kernel as it wasn't complete on 4.4 kernel). At that time, the functionality itself existed, but it did nothing.
And as for the wm not changing the resolution we see... does it mean the panel is still outputting at 1080p even when instructed to change to 4K? If so, the "4K" is actually achieved via GPU scaling (which is also possible on desktop video cards, to attain a virtual 4K resolution on a 1080p-only monitor). This makes the 4K support claim fake, as it's not a real 4K resolution, but rather 4K rendered in background then downscaled to 1080p when outputting to the panel as the panel is operating at 1080p.
LSS4181 said:
So it seems we need to also alter the HAL to get the correct FPS. But the interesting phenomenon is, altering the kernel to use 120Hz, without touching any other code, triggers the HAL to render at 24 FPS instead of 60 FPS. This might be a hint on where we need to look at in the HAL code, if possible. I haven't tried other combinations, only 90 and 120, with the former having no impact (60 FPS).
As for you saying the SOMC kernel using a driver wonky to the AOSP standard might explain why it's been so complicated to get DRS (Dynamic Resolution Switching) to actually work despite the functionality's already been implemented in the SonyOpenDevices project (which is NOT what current CarbonROM is based on). Not sure about the functionality in AOSP now, but it's been non-working for quite a while (at least up to the point of switching to the 4.9 kernel as it wasn't complete on 4.4 kernel). At that time, the functionality itself existed, but it did nothing.
And as for the wm not changing the resolution we see... does it mean the panel is still outputting at 1080p even when instructed to change to 4K? If so, the "4K" is actually achieved via GPU scaling (which is also possible on desktop video cards, to attain a virtual 4K resolution on a 1080p-only monitor). This makes the 4K support claim fake, as it's not a real 4K resolution, but rather 4K rendered in background then downscaled to 1080p when outputting to the panel as the panel is operating at 1080p.
Click to expand...
Click to collapse
The 24 thing seems more like a glitch to me, personally. Since Android was never designed to support high refresh rates. Maybe in Android Q, hey?
By wonky I meant they use a different.. unusual method of seemingly having a display for each resolution (and one for 120hz) which are switched between or something like that. An interesting fact is if you're watching 4k and screenshot you get a black screen. I've noticed Windows 10 doing a similar thing in their recent closed Insider beta.
Yes the panel outputs 1080p even with a 4k resolution as the window manager (wm) only controls how much it processes not the output, without the HALs allowance. Yupp is 4k rendered them down to 1080p and breaks screenshots. You can easily tell by looking at a 4k picture in any app and then album with the stock wm.
Is 120Hz still being worked on? its been nearly a year since it was discovered and i thought it would be working by the end of the year at least. coming from the XZ
XxperexX said:
Is 120Hz still being worked on? its been nearly a year since it was discovered and i thought it would be working by the end of the year at least. coming from the XZ
Click to expand...
Click to collapse
Thanks to Bartcubbins/Pavel we're pretty close to getting it on stock on my kernel.
For custom ROMs they've had it for ages.
LazerL0rd said:
Thanks to Bartcubbins/Pavel we're pretty close to getting it on stock on my kernel.
For custom ROMs they've had it for ages.
Click to expand...
Click to collapse
I follow your project[emoji6]
Envoyé de mon G8141 en utilisant Tapatalk
LazerL0rd said:
Thanks to Bartcubbins/Pavel we're pretty close to getting it on stock on my kernel.
For custom ROMs they've had it for ages.
Click to expand...
Click to collapse
im running omni 8.1.0 custom rom on my XZ and it has the toggle for it, but it doesnt work i understand that u probs only work on the XZP, but at least work is being done on it
Any new updates? or is it still WiP?
LazerL0rd said:
Thanks to Bartcubbins/Pavel we're pretty close to getting it on stock on my kernel.
For custom ROMs they've had it for ages.
Click to expand...
Click to collapse
Which roms?
razerphynx said:
Which roms?
Click to expand...
Click to collapse
Idk but it's been available to all SODP for some time.

Categories

Resources