Related
I responded in the larger CM9 thread but it will probably be buried in a day or so. And I think this will help devs who are working on CM9 builds at the moment.
------------------------------------------------------------------
jdommer said:
The correct settings for the our touch screen appear to be:
Code:
touch.deviceType = touchScreen
touch.orientationAware = 1
# Size
# Based on empirical measurements, we estimate the size of the contact
# using size = sqrt(area) * 28 + 0.
touch.size.calibration = default
touch.size.scale = 1
touch.size.bias = 0
touch.size.isSummed = 0
# Pressure
# Driver reports signal strength as pressure.
#
# A normal index finger touch typically registers about 80 signal strength
# units although we don't expect these values to be accurate.
touch.pressure.calibration = none
touch.pressure.scale = 1.0
# Orientation
touch.orientation.calibration = default
Unfortunately, that doesn't do anything for the tap/drag problem. The KF can't distinguish pressure or size of touch.
Looks like Android decides any touch where x1-x2 or y1-y2 > 8 as a drag. I can't find any place that that value is configurable after scouring the internets all morning, but if it could simply be turned up to maybe 12 that would probably alleviate 90% of our taps as drags problems.
Anyone have any idea, is there a config file or is that compiled in and has to be changed at source? I feel competent enough to dink with config files, but can't compile crap.
Click to expand...
Click to collapse
I build from the KFire-Android git as a testing model and i've been experimenting with a setting of "16" for touch slop, and in my opinion it's working much better.. could probably be 12, but who knows. I'm having a much easier time selecting things like Beautiful Widgets 1x1 Toggles, where before it was a trial of patience and about 10 touches.
This is a setting in the overlay config.xml file. I went ahead and committed it this morning to the KFire-Android org at Github:
https://github.com/KFire-Android/device-amazon-otter/commit/56b3d52fe6c645a18e60ab765e5b9831cb6a0663
Is the code that uses the clickSlop in android hackable for KFire?
I found on my device that most of the noise on taps was occurring in the last few samples (like the touchscreen firmware is averaging in some bad samples on finger release) and that by dropping the last few touch events I got much better touch response in my app. I'm not sure where to put such a state machine in the framework, though, or how to have it only for KFire...
(My state machine would buffer 3 samples ahead for the first 20 samples, and then drop the last 3 samples on finger up and patch N-3 to be a finger up instead of a move -- after 20 samples it just passed everything through with no buffering to avoid adding latency to drags).
Ok - you may be familiar with my mod here -
http://forum.xda-developers.com/hon...ipt-disable-enable-swap-honor-5x-kiw-t3308321
If not - try it - but in any case, from that thread, get SH Script Runner, Stericson's Busybox Installer
What this mod is about -
Makes your phone act like it's 720p instead of 1080p
It's still 1080p
But it moves the work from the GPU to the screen's hardware scaler
There's no such thing as a free lunch so this won't give you more battery duration
This may screw up your favorite keyboard, like SwiftKey - use the Google keyboard
This may screw up your icon sizes in your launcher (so look for launcher options to change that if you care)
This is going to make your fonts smaller in many places
This mod is not guaranteed to work the way you want
You MUST make a nandroid backup before proceeding if you know what's good for you
Run this the same way as you would my swap scripts
What this mod contains -
dpi-switch.zip that you unzip at the top of your /sdcard
If you followed the swap script instructions, you already knew that
720p.sh does exactly what the name implies - it's the mod
1080p.sh does what the name implies - it restores your phone to the default state
You must be root to run - see the instructions - turn on the SU button in SH Script Runner
Your phone will reboot when done
I may or may not change that
What could possibly go wrong -
If you use this with other DPI or screen mods, the sky could fall, your friends will leave and your dog will disown you - plus your phone will be borked
You didn't ignore me, you made a nandroid backup so nothing really bad can happen if you did
The screen may start out as tiny - play with it some, it will sort itself out - maybe even hold power to kill it and start it again
I can reproduce that but not every time
You can get the right sized screen and be fine, just play with it if it hits you
Try turning to landscape and back, that seems to clear it up too
That only happens right after the mod is applied
Important things to know about this mod -
No puppies were harmed during its creation
I am not responsible if your phone dies, catches fire, blows up, tries to take over the world, or starts running like a bat out of hell and makes you very happy
OK, I'm a little bit responsible for that last bit but only a little
Monjori OpenGL Shader benchmark test - 49 fps stock, 62 fps modded
PERFECTLY SAFE TO GO BACK AND FORTH FROM 720 TO 1080 AT ANY TIME
Enjoy - if it's pretty necessary, I'll come back with pictures - but seriously - see the swap thread linked about - this just copies the same approach, and just gives you some new commands.
Cheers!
PS - Yes - you can too do this yourself or use some other apps. No - nothing is as easy as doing it this way if you're not an expert in these things - that's why I made this for you.
Download is right here -
View attachment dpi-switch.zip
Here are the codes:
720p -
Code:
#!/system/bin/sh
# Sets 720p windows defaults on 1080p 5.5" Huawei, such as honor 5x
# Must run as root
# WILL reboot when finished!
# March 19, 2016
# EarlyMon
wm size 720x1280
wm density 320
setprop sys.powerctl reboot
1080p -
Code:
#!/system/bin/sh
# Restores 1080p windows defaults on Huawei, such as honor 5x
# Must run as root
# WILL reboot when finished!
# March 19, 2016
# EarlyMon
wm size reset
wm density reset
setprop sys.powerctl reboot
Is it the same as running
adb shell wm size 720x1280
adb shell wm density 320
adb reboot
Through adb or are there changes in value ?
Edit: I looked into the files and saw a change in density, 267 instead of 320...would it work with 320 ?
Zakaria.R said:
Is it the same as running
adb shell wm size 720x1280
adb shell wm density 320
adb reboot
Through adb or are there changes in value ?
Edit: I looked into the files and saw a change in density, 267 instead of 320...would it work with 320 ?
Click to expand...
Click to collapse
Yep, basically the same thing. There are namespace and zygote differences from Huawei so things in a terminal emulator aren't always the same as when run through adb, so we need root here.
267 comes from Pythagoras -
sqrt( 720^2 + 1280^2 ) / 5.5 = 267
320 is the class value understood by services and both work equally well.
I've updated the script to the use the 320 class value for density and went ahead and changed shutdown to reboot - I've seen occasional weirdness with just a reboot, but the first post instructions say if it's weird, try a shutdown anyway.
I'm not sure the changes make a difference but you're right - most folks familiar with this will expect the class value there, so I've changed the script.
And as I mentioned at the end of the post - no magic, nothing you can't do yourself if you know how, just a lot easier this way for non-experts.
Cheers!
PS - added the script codes to the second post, no secrets to this.
EarlyMon said:
Yep, basically the same thing. There are namespace and zygote differences from Huawei so things in a terminal emulator aren't always the same as when run through adb, so we need root here.
267 comes from Pythagoras -
sqrt( 720^2 + 1280^2 ) / 5.5 = 267
320 is the class value understood by services and both work equally well.
I've updated the script to the use the 320 class value for density and went ahead and changed shutdown to reboot - I've seen occasional weirdness with just a reboot, but the first post instructions say if it's weird, try a shutdown anyway.
I'm not sure the changes make a difference but you're right - most folks familiar with this will expect the class value there, so I've changed the script.
And as I mentioned at the end of the post - no magic, nothing you can't do yourself if you know how, just a lot easier this way for non-experts.
Cheers!
PS - added the script codes to the second post, no secrets to this.
Click to expand...
Click to collapse
Appreciate the explanation good job my friend keep up
Performance Impact for 2D games
I notice my phone is bit laggy when I play 2D game with 720p mode. I doubt scaler is overloaded.
So I compare both score with GFX benchmark.
Here are texturing results. 720p score was about 1270, native was about 1400.
720p mode impact some 2D performance by use hardware scaler always.
Same benchmark shows improvement in other areas - there's no simple answer and this is a mod to use when it benefits games that get along with it. As you've found, not all do.
EarlyMon said:
Same benchmark shows improvement in other areas - there's no simple answer and this is a mod to use when it benefits games that get along with it. As you've found, not all do.
Click to expand...
Click to collapse
Strong agree.
I decided my phone to leave default. 'cause for me, more suitable than 720p. But someone is not.
Not simple.
Here are all results for comparison. for someone.
On my KIW-L21 the Screen did not scale, unfortunately.
Meaning the Screen with a resolution of 720p was stuck in the upper left corner of the screen(Like a window, the rest of the screen was black),
while the touch input was rooted from the whole screen, which made it a little bit challenging to operate the device
Any idea how one could tackle that problem?
Nekly said:
On my KIW-L21 the Screen did not scale, unfortunately.
Meaning the Screen with a resolution of 720p was stuck in the upper left corner of the screen(Like a window, the rest of the screen was black),
while the touch input was rooted from the whole screen, which made it a little bit challenging to operate the device
Any idea how one could tackle that problem?
Click to expand...
Click to collapse
1. Enable auto-rotate. Then rotate your phone at lock screen.(See #1)
2. Try edit script "wm density 267" instead of 320. Use SH script runner on root mode. (See #3~)
3. Try adb command via PC (see #3) if you feel too difficult to operate with touch screen.
I counter same problem. I resolve this with 3. 'cause I can't unlock my phone
ssrnsrsr said:
1. Enable auto-rotate. Then rotate your phone at lock screen.(See #1)
2. Try edit script "wm density 267" instead of 320. Use SH script runner on root mode. (See #3~)
3. Try adb command via PC (see #3) if you feel too difficult to operate with touch screen.
I counter same problem. I resolve this with 3. 'cause I can't unlock my phone
Click to expand...
Click to collapse
1. Autorotate is on. Does not do anything.
2. Edited the script to uses 267 density. Did not work either.
3. ADB kinda works with density 320. I could test, wether to use this mod or not. But in my Use Case I got no benefit whatsoever. Also not beeing able to change this on the go is another deal breaker to me.
Thanks for the support.
I have the same results as Nekly. After digging deeper, the problem lies within the EMUI 3.1 launcher. After you change the resolution/density, the icons look all jacked. I opened some games, and the games look just fine. There is definitely a noticeable FPS boost.
There's no such thing as a free lunch so this won't give you more battery duration
Click to expand...
Click to collapse
After careful thought, I tend to disagree with this statement. While the screen is off, hes right, there is no free lunch there. While I have not tested it, in theory it *should* result in more battery duration while you are using the phone. My theory is that if you were to change the resolution to 720x1280 thats 921600 total pixels rendered on the screen. Instead of the normal 1080x1920 which is 2073600 total pixels rendered. Thats a net difference of 1161000 less pixels that the GPU has to render. So less work for the GPU. The MHZ will still be the same so no change there. If there was no FPS boost in the game, then the GPU would still be doing the same amount of work. But there is an FPS boost.
This is an awesome tweak, I wish I could get the launcher to display the icons correctly. Again great work @EarlyMon!
TouchOdeath said:
I have the same results as Nekly. After digging deeper, the problem lies within the EMUI 3.1 launcher. After you change the resolution/density, the icons look all jacked. I opened some games, and the games look just fine. There is definitely a noticeable FPS boost.
After careful thought, I tend to disagree with this statement. While the screen is off, hes right, there is no free lunch there. While I have not tested it, in theory it *should* result in more battery duration while you are using the phone. My theory is that if you were to change the resolution to 720x1280 thats 921600 total pixels rendered on the screen. Instead of the normal 1080x1920 which is 2073600 total pixels rendered. Thats a net difference of 1161000 less pixels that the GPU has to render. So less work for the GPU. The MHZ will still be the same so no change there. If there was no FPS boost in the game, then the GPU would still be doing the same amount of work. But there is an FPS boost.
This is an awesome tweak, I wish I could get the launcher to display the icons correctly. Again great work @EarlyMon!
Click to expand...
Click to collapse
0.5 × 2 = 1
If you render half as many pixels per frame but increase the number of frames per second by what could be a factor of two, then the system theoretically ends up rendering the same number of pixels per second.
(pixels/frame × frames/second = pixels/second)
GPUs and displays work on fields - even the LCD control matrix doesn't have to refresh in terms of pixels - so the math is actually quite a bit more complex for making predictions.
If you get better battery performance, great!
But I won't promise that because TANSTAAFL.
Nice!! Very deep insight, love the formula!!
Loving these small but useful script contributions, Mon. Thanks for the hard work. Will definately try this when I get home. Question - is the effect on the icons on the native launcher only? I removed that from /system and installed Nova as my only and default launcher, so just wondering if it's Huawei's fault or just a secondary effect from the resolution change.
I have the same results as Nekly. After digging deeper, the problem lies within the EMUI 3.1 launcher. After you change the resolution/density, the icons look all jacked.
Click to expand...
Click to collapse
What I said in the above quote is wrong. Nekly does a great job in describing the problem:
On my KIW-L21 the Screen did not scale, unfortunately.
Meaning the Screen with a resolution of 720p was stuck in the upper left corner of the screen(Like a window, the rest of the screen was black),
while the touch input was rooted from the whole screen, which made it a little bit challenging to operate the device
Any idea how one could tackle that problem?
Click to expand...
Click to collapse
I'm experiencing the exact same problem on my L24 as @Nekly and I now have a ghetto solution.
There is an app called Resolution Changer. It has widgets you can place on your desktop. I have two widgets, a 720p and a 1080p. When the device is rebooted, the resolution will screw up, all you have to do is click on the 1080p, and it will restore fullscreen. Then click on 720p widget, and your screen will be fullscreen 720p. I'll post a better solution when I find one.
+1 to @EarlyMon for coming up with this geniusry. This tweak is clutch.
Can anybody get me a flashable zip that resets the resolution back to 1080p? I used the Resolution Changer app and somehow I screwed up my display. Any help would be appreciated!
EDIT: found this -->https://forum.xda-developers.com/android/general/guide-fixing-resolution-using-nomone-t2921856, this guy saved my day, but it would be more convenient when having a flashable zip file instead of having to connect to a computer and reset res via adb. Cheers!:good:
I want to lower the device resolution to 1920x1080 to give the phone a bit more snappiness, maybe even more battery life.
I found a thread that has done it ----> This thread
However using the commands
wm size 1080x1920
wm density 441
does not work running android M
I am running the AOSP - CAF rom
Has anyone done succeeded at doing this on android M?
I've had no issue using the wm command on any versions of XenonHD on my d855. I have always used Nomone resolution changer to check the current resolution. But the terminal commands work for me whether the apps installed or not.
If I remember rightly some ROMs have issues with changing density "wm density" to a lower value, but that can be rectefied by changing (or adding) "ro.sf.lcd_density=" in the build prop. I have my wm density set to 320 and my buildprop to "560"
I think you may need to report this issue in your ROMs forum thread to get more accurate advice though. Like I said, I've never had any problems on XenonHD with ACC1.6 kernel.
Link420able said:
I want to lower the device resolution to 1920x1080 to give the phone a bit more snappiness, maybe even more battery life.
I found a thread that has done it ----> This thread
However using the commands
wm size 1080x1920
wm density 441
does not work running android M
I am running the AOSP - CAF rom
Has anyone done succeeded at doing this on android M?
Click to expand...
Click to collapse
its useless to downgrade your resolution to 1080p.there will be 0% improvement on battery and a minor 10-20% boost in gpu performance.it will make your g3 look ugly so better not do that.if u want better battery life go fo some 3rd party batteries like zerolemon and others
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.
Got a V30 a few months ago - brilliant device but not that happy with the display - it has the very annoying "black crush" issue for me.
Short explanation (it's better you don't read - trust me it can be very annoying when you're aware of it):
The lower the screen brightness is set, dark grays and dark colours are shown completely black when they shouldn't - this is very annoying as the detail in darker areas of images completely disappears (it's bad for all content - pictures, videos, games). It can vary from device to device, even on the same models.
This is an issue at varying degrees on other OLEDs too such as Pixels', Samsung, OnePlus; but Apple and Huawei seem keep it mostly under control. Funny enough my old Galaxy S4 does not really have this issue.
Google and Samsung managed to partially fix it (completely for some users) with software updates, so this should be possible for us too especially as V30 has the exact same display as Pixel 2 XL which got some improvement via update if I remember correctly.
There are apps and tricks which claim to improve this but while they can help a bit they bring in other issues.
Looking for fixes I found this V30 kernel - "Savitar-OC-kernell" - a claimed feature was refresh rate OC (80Hz). The thread is closed, the links are dead, the dev didn't respond (PM'd months ago) and there is no video proof of it so I can't really be sure that it worked well or at all. But if true then it means there is at least a way to get very low level control of the display panel.
I have zero experience with kernel/ROM development but I can get technical so I did some (probably bad) research myself. Downloaded the kernel source from LG.
Found some interesting files here:
...\kernel\msm-4.4\drivers\video\fbdev\msm\lge\joan\
...\kernel\msm-4.4\arch\arm64\boot\dts\lge\
My guess is that V30's panel is "sw43402" (I think that's the driver IC model, same as 2 XL) - there are multiple files for it, with values for front/back porch, clk etc. which is what I suspect was modified for the refresh overclock.
Also found multiple entries/tables? for "gamma" and "blmap" (backlight map?) values which is what I hope can be used for a fix for the black crush.
My hope is that there is a way to tweak the gamma curves or some other form of display mapping. At 100% brightness my phone display is almost perfect, zero black crush. However as I set the brightness lower the black crush amount varies (it's not linear or exponential, it's "jumpy") which looks like there is some sort of mapping trying to compensate.
I'd love to hear your opinion especially if you have any experience with this stuff or if you can forward this to someone you know could answer. I would appreciate if you can tell whether you think this is possible and whether what I found is on the right track. Thanks for reading all this.
gamma correction
Click to expand...
Click to collapse
your best bet is via KCAL or KLAPSE in custom kernels
recommendation-based is to not go lower than 30 or 50% in brightness otherwise you'll lose details
refresh rate overclocking
Click to expand...
Click to collapse
not worth it, there's no true close hardware manipulation possible (like with Exynos kernel source) also OLED panels are sensitive (high brightness, burn-in, etc.) and (relatively?) short-lived already - why shortening life even more ?
Thanks for the reply.
KCAL seems to be a step in the right direction however I don't think I can find any kernel for V30 that has it. I'll look into KLAPSE but it seems that it won't help "out of the box" without some lower level modifications.
Refresh rate - sure it may not be very practical but I don't think it's that dangerous (One example being the overclocked Note 3 displays in the Oculus DK2 back in 2014). 80Hz may be too much (and may be ghosting) but even 67-72 should make a noticeable difference. And why not have it as an option - for science - or for people that plan to upgrade soon and want to go crazy with it.
zacharias.maladroit said:
there's no true close hardware manipulation possible
Click to expand...
Click to collapse
Can you please expand on this? What about the files I mentioned? An example snippet from
dsi-panel-sw43402-dsc-qhd-cmd-dv2_0.dtsi
Code:
[FONT="Courier New"]...
&mdss_mdp {
dsi_sw43402_dsc_qhd_cmd_dv2_0: qcom,mdss_dsi_sw43402_dsc_qhd_cmd_dv2_0 {
qcom,mdss-dsi-panel-name = "SW43402 cmd mode dsc dsi panel";
qcom,mdss-dsi-panel-type = "dsi_cmd_mode";
qcom,mdss-dsi-panel-framerate = <60>;
qcom,mdss-dsi-virtual-channel-id = <0>;
qcom,mdss-dsi-stream = <0>;
qcom,mdss-dsi-panel-width = <1440>;
qcom,mdss-dsi-panel-height = <2880>;
qcom,mdss-dsi-h-front-porch = <92>;
qcom,mdss-dsi-h-back-porch = <48>;
qcom,mdss-dsi-h-pulse-width = <32>;
qcom,mdss-dsi-h-sync-skew = <0>;
qcom,mdss-dsi-v-back-porch = <25>;
qcom,mdss-dsi-v-front-porch = <10>;
qcom,mdss-dsi-v-pulse-width = <1>;
...[/FONT]
I'd imagine something should happen if these are modified, or do you think nothing would happen? Some gamma and blmap tables are also further down in the file.
However there are multiple similar files in that folder which is a bit confusing to me. Any clue if there's public documentation on this or at least what to search for to understand it further?
cLick1338 said:
Got a V30 a few months ago - brilliant device but not that happy with the display - it has the very annoying "black crush" issue for me.
Short explanation (it's better you don't read - trust me it can be very annoying when you're aware of it):
The lower the screen brightness is set, dark grays and dark colours are shown completely black when they shouldn't - this is very annoying as the detail in darker areas of images completely disappears (it's bad for all content - pictures, videos, games). It can vary from device to device, even on the same models.
This is an issue at varying degrees on other OLEDs too such as Pixels', Samsung, OnePlus; but Apple and Huawei seem keep it mostly under control. Funny enough my old Galaxy S4 does not really have this issue.
Google and Samsung managed to partially fix it (completely for some users) with software updates, so this should be possible for us too especially as V30 has the exact same display as Pixel 2 XL which got some improvement via update if I remember correctly.
There are apps and tricks which claim to improve this but while they can help a bit they bring in other issues.
Looking for fixes I found this V30 kernel - "Savitar-OC-kernell" - a claimed feature was refresh rate OC (80Hz). The thread is closed, the links are dead, the dev didn't respond (PM'd months ago) and there is no video proof of it so I can't really be sure that it worked well or at all. But if true then it means there is at least a way to get very low level control of the display panel.
I have zero experience with kernel/ROM development but I can get technical so I did some (probably bad) research myself. Downloaded the kernel source from LG.
Found some interesting files here:
...\kernel\msm-4.4\drivers\video\fbdev\msm\lge\joan\
...\kernel\msm-4.4\arch\arm64\boot\dts\lge\
My guess is that V30's panel is "sw43402" (I think that's the driver IC model, same as 2 XL) - there are multiple files for it, with values for front/back porch, clk etc. which is what I suspect was modified for the refresh overclock.
Also found multiple entries/tables? for "gamma" and "blmap" (backlight map?) values which is what I hope can be used for a fix for the black crush.
My hope is that there is a way to tweak the gamma curves or some other form of display mapping. At 100% brightness my phone display is almost perfect, zero black crush. However as I set the brightness lower the black crush amount varies (it's not linear or exponential, it's "jumpy") which looks like there is some sort of mapping trying to compensate.
I'd love to hear your opinion especially if you have any experience with this stuff or if you can forward this to someone you know could answer. I would appreciate if you can tell whether you think this is possible and whether what I found is on the right track. Thanks for reading all this.
Click to expand...
Click to collapse
The savitar kernel dev is still active and made a new kernel, tachyon kernel that is, but he remove the 80hz because it doesnt work on real life test. All the kernel for v30 have kcal btw (there are only 2 kernel which is ceres (or lunar or orion or any other name that the dev like to named before) by @zacharias.maladroit and tachyon ( or some other name that i swear i cant remember) by @darkidz555
---------- Post added at 02:03 PM ---------- Previous post was at 01:59 PM ----------
cLick1338 said:
Thanks for the reply.
KCAL seems to be a step in the right direction however I don't think I can find any kernel for V30 that has it. I'll look into KLAPSE but it seems that it won't help "out of the box" without some lower level modifications.
Refresh rate - sure it may not be very practical but I don't think it's that dangerous (One example being the overclocked Note 3 displays in the Oculus DK2 back in 2014). 80Hz may be too much (and may be ghosting) but even 67-72 should make a noticeable difference. And why not have it as an option - for science - or for people that plan to upgrade soon and want to go crazy with it.
Can you please expand on this? What about the files I mentioned? An example snippet from
dsi-panel-sw43402-dsc-qhd-cmd-dv2_0.dtsi
Code:
[FONT="Courier New"]...
&mdss_mdp {
dsi_sw43402_dsc_qhd_cmd_dv2_0: qcom,mdss_dsi_sw43402_dsc_qhd_cmd_dv2_0 {
qcom,mdss-dsi-panel-name = "SW43402 cmd mode dsc dsi panel";
qcom,mdss-dsi-panel-type = "dsi_cmd_mode";
qcom,mdss-dsi-panel-framerate = <60>;
qcom,mdss-dsi-virtual-channel-id = <0>;
qcom,mdss-dsi-stream = <0>;
qcom,mdss-dsi-panel-width = <1440>;
qcom,mdss-dsi-panel-height = <2880>;
qcom,mdss-dsi-h-front-porch = <92>;
qcom,mdss-dsi-h-back-porch = <48>;
qcom,mdss-dsi-h-pulse-width = <32>;
qcom,mdss-dsi-h-sync-skew = <0>;
qcom,mdss-dsi-v-back-porch = <25>;
qcom,mdss-dsi-v-front-porch = <10>;
qcom,mdss-dsi-v-pulse-width = <1>;
...[/FONT]
I'd imagine something should happen if these are modified, or do you think nothing would happen? Some gamma and blmap tables are also further down in the file.
However there are multiple similar files in that folder which is a bit confusing to me. Any clue if there's public documentation on this or at least what to search for to understand it further?
Click to expand...
Click to collapse
Btw, @zacharias.maladroit motto for kernel development is stability and longevity so asking him for OC is not possible
Quick update, tried KCAL, only helps a little bit, but even on the most extreme settings it's barely effective.
KLAPSE has no means of improving it but I'm thinking something could be done by using the "brightness based scaling" and unlocking the "dimming" function to be able to actually brighten the image too. Currently it only goes from 20% to 100%, so it has to be able to go over 100% which I'm not sure is easy or possible.