Related
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.
The following command is how you can toggle HBM on our 6 Pro:
Code:
echo 1 > /sys/devices/platform/1c2c0000.drmdsim/1c2c0000.drmdsim.0/backlight/panel0-backlight/hbm_mode
Replace the one with a zero to disable!
HBM = high brightness mode?
Is it worth doing?
Cares said:
HBM = high brightness mode?
Is it worth doing?
Click to expand...
Click to collapse
I prefer doing it through @flar2 's HBM app set to automatic when using his custom ElementalX kernel. They've made that kernel for each of the previous Pixels (and some other phones) so I expect once the source code drops they'll do so for the P6P as well.
It definitely made a difference in direct sunlight.
Yeah I use Tasker to create QS toggle with that command
Is the command through adb? Or terminal?
rickysidhu_ said:
The following command is how you can toggle HBM on our 6 Pro:
Code:
echo 1 > /sys/devices/platform/1c2c0000.drmdsim/1c2c0000.drmdsim.0/backlight/panel0-backlight/hbm_mode
Replace the one with a zero to disable!
Click to expand...
Click to collapse
Any known downsides? I'm curious if there's no long term ill effects why it isn't just a default option. Any chance what's built in is 'what works for every panel' but HBM might cause an issue with a borderline panel that just barely squeaked through QA?
rickysidhu_ said:
The following command is how you can toggle HBM on our 6 Pro:
Code:
echo 1 > /sys/devices/platform/1c2c0000.drmdsim/1c2c0000.drmdsim.0/backlight/panel0-backlight/hbm_mode
Replace the one with a zero to disable!
Click to expand...
Click to collapse
I was playing around with this command a couple of days ago because I didn't feel that the maximum brightness was very good due to the Pixel 6 Pro using a Samsung s6e3hc3 display (cat /sys/class/backlight/panel0-backlight/device/panel_name), which is in fact the same display the Oppo Find X3 Pro uses & allegedly that goes upto 1300 nits.
I found that:
echo 1 >> /sys/class/backlight/panel0-backlight/hbm_mode
and
echo 2 >> /sys/class/backlight/panel0-backlight/hbm_mode
Both work to give the Pixel 6 Pro to achive a little more brightness (& they stay on after switching the screen off) - obviously setting HBM to "1" provides a little more brightness than "0", and "2" provides even more brightness than "1".
I used my ColourMunki Display to measure the brightness of the display multiple times & got the same results every time: these show that max brightness with HBM @ 0 is ~500 nits, HBM @ 1 is ~795 nits & HBM @ 2 provides 835 nits.
I'm hoping someone can replicate these numbers or verify with another, more accurate device & hopefully (when ElementalX is released) we will be able to toggle both HBM modes via the HBM widget
It also works on my Pixel 6 (non-pro), good to know, thanks!
I guess this is root-only?
Morgrain said:
I guess this is root-only?
Click to expand...
Click to collapse
Yeah, you'd get "permission denied" if you try to echo to that directory without su permissions
roirraW edor ehT said:
I prefer doing it through @flar2 's HBM app set to automatic when using his custom ElementalX kernel. They've made that kernel for each of the previous Pixels (and some other phones) so I expect once the source code drops they'll do so for the P6P as well.
It definitely made a difference in direct sunlight.
Click to expand...
Click to collapse
Yeah, in the past I've been doing it with tbalden's CleanSlate kernel, which comes with QS toggles. He even has a High Brightness mode & a High Brightness Boost mode, which goes even beyond what High Brightness gives you. But until (or if) he builds his kernel for this phone I'm using flar2's HBM mode app and just toggle it on if I need to.
The other day I went into the bright sun for the first time with this phone to test it's native HBM abilities (without flar2's app). It definitely appeared to turn on by itself (took about 3-5 seconds), which is different from my Pixel 4 XL, where the HBM mode was disabled and hidden by default. The screen was also plenty bright for me to see, so I think all this talk about it not having enough Nits or not being bright enough is a bit exaggerated.
It's definitely not as bright as my op8 pro. I work outside so I always use flars hbm. I'm using it still but it's a little glitchy
Lughnasadh said:
The other day I went into the bright sun
Click to expand...
Click to collapse
Lughnasadh said:
The screen was also plenty bright for me to see, so I think all this talk about it not having enough Nits or not being bright enough is a bit exaggerated.
Click to expand...
Click to collapse
Can agree with this. Even with bright sunshine outside, I can still see everything without problem & sunglasses on (stock, no root, no forced HBM). That's the most extreme usecase I can think of, so that's fine on my end.
Ultimoose said:
Any known downsides? I'm curious if there's no long term ill effects why it isn't just a default option. Any chance what's built in is 'what works for every panel' but HBM might cause an issue with a borderline panel that just barely squeaked through QA?
Click to expand...
Click to collapse
There might be a possible downside of screen burn in for having HBM on for extended periods. Maybe poor battery life as well.
I don't think there's a default option because I think Android will enable it automatically when the device is under bright light. This command lets you use the mode in any lighting condition
If I'm incorrect with any of this information, anyone who knows more, feel free to let us know!
rickysidhu_ said:
There might be a possible downside of screen burn in for having HBM on for extended periods. Maybe poor battery life as well.
I don't think there's a default option because I think Android will enable it automatically when the device is under bright light. This command lets you use the mode in any lighting condition
If I'm incorrect with any of this information, anyone who knows more, feel free to let us know!
Click to expand...
Click to collapse
Thank you sir for the information, appreciate it!
Ultimoose said:
Any known downsides? I'm curious if there's no long term ill effects why it isn't just a default option. Any chance what's built in is 'what works for every panel' but HBM might cause an issue with a borderline panel that just barely squeaked through QA?
Click to expand...
Click to collapse
I used automatic HBM through @flar2 's ElementalX kernel and app on my Pixel 1 for several years - I never experienced any issues. It definitely made the screen brighter in direct sunlight than the Pixel 1 did by itself without the kernel and app.
DanielF50 said:
I was playing around with this command a couple of days ago because I didn't feel that the maximum brightness was very good due to the Pixel 6 Pro using a Samsung s6e3hc3 display (cat /sys/class/backlight/panel0-backlight/device/panel_name), which is in fact the same display the Oppo Find X3 Pro uses & allegedly that goes upto 1300 nits.
I used my ColourMunki Display to measure the brightness of the display multiple times & got the same results every time: these show that max brightness with HBM @ 0 is ~500 nits, HBM @ 1 is ~795 nits & HBM @ 2 provides 835 nits.
Click to expand...
Click to collapse
Following up on this, I tested some HDR10+ videos on YouTube & if you run cat /sys/class/backlight/panel0-backlight/hbm_mode, when these are playing, you get a result of HBM: "1" so the kernel is obviously able to use this feature on a stock device, and maybe even utilises this when in extreme lighting conditions.
I've update High Brightness Mode to support Pixel 6/6Pro (version 5.03).
High Brightness Mode - Apps on Google Play
See your screen in bright sunshine. High brightness mode for your phone
play.google.com
flar2 said:
I've update High Brightness Mode to support Pixel 6/6Pro (version 5.03).
Click to expand...
Click to collapse
Thank you!!
flar2 said:
I've update High Brightness Mode to support Pixel 6/6Pro (version 5.03).
High Brightness Mode - Apps on Google Play
See your screen in bright sunshine. High brightness mode for your phone
play.google.com
Click to expand...
Click to collapse
Does it support the "2" mode described above by @DanielF50 ?
forum.xda-developers.com/t/hbm.4356189/post-85878625
Hi, good members of xda!
Recently flashed AICP custom rom on my poco f3 also have rooted via magisk
It seems that refresh rate mechanism would lock it on peak refresh rate(Settings-Additional device settings-Peak Refresh Rate) in following games(even though they don't support 120hz, which caused screen juddering):
***120hz compatibility verified using multiple sources***
Source 1 Source 2
Asphalt 9 Legends
Genshin Impact
#DRIVE
I love Hue(Supported, but refresh rate switching is very aggressive goes back and forth a lot)
Darkness Rises(Supported, but I have 60fps enabled, yet refresh rate is 120hz anyway)
....
I have a few questions:
1-Can I force 60hz on specific games or apps? (something like per-app profile in FK kernel manager source but with an option for refresh rate)
2-Is refresh rate switch mechanism mainly related to display panel or software?
3-should I find relevant forum of each game or open a thread on Mi forums?
Thanks in advance!
Hi there, if you can't do it in other way, you can install macrodroid and make a macro that everytime you start those games it automatcally switches the maximum refresh rate to 60hz, and when you leave the game it switches back to 120hz, easy stuff to do...
Macrodroid can switch refresh rate too? Didn't know.. I mean I used macrodroid before, but since didn't have any HRR device, didn't think it could do it.
Edit: know I realize, scripting? Hmmm... Will search around and see how to do so...
Shadowk1ller said:
Hi there, if you can't do it in other way, you can install macrodroid and make a macro that everytime you start those games it automatcally switches the maximum refresh rate to 60hz, and when you leave the game it switches back to 120hz, easy stuff to do...
Click to expand...
Click to collapse
I used macrodroid, still no luck.. Tried a lot of combinations
Via md helper
md helper log, it seems it wants adb access... Interesting turn of events
Will grant and see what happens
Granted adb, peak refresh rate changed, still in game it says 120hz
That's very strange, maybe there are two places you can change the refresh rate on that rom? If i remember correctly, on the first builds or crdoird i could change the refresh rate on display settings and on crdroid settings, if i changed it on display settings, after a reboot the settings reverted, but if i changed it on crdroid settings it would remain changed... I dont know if that rom as the same or maybe two places with the same setting...
Well, I don't know either.. I posted a thread on macrodroid forum too.. Maybe guys over there can help
Thanks a bunch!
I'll keep experimenting with this matter... Since I have quite a lot of free time!
Still not a reply on macrodroid forum and not even a view! My luck seems to be dried AF!
[Tested. Works as of One UI 4.1 September, 2022 Patch AVHH Build]
Hello again! A handful of you may have seen my S21 guide for forcing 120Hz through pretty much every app and while the camera is active (looking at you, Snapchat!!). The previous guide doesn't apply to the S22 series because Samsung changed the range of valid refresh rate values all the way down to 1Hz.. WELL I still managed to break it... 0.1Hz as a value apparently works.
A kind user made a video based on my guide: Linked;
I also want to say that the August update seems to have broken something for some users, but I've re-applied this on said update and it still works fine on my end.
This is also for allowing 120Hz when the camera is active; not so much forcing 120Hz (some users got confused because of my poor choice of wording).
Before you start, make sure your refresh rate is set to Adaptive.
1. Download SetEdit from the google play store.
2. Open up to the system table.
3. At the very top, you'll see an option to add a new setting. Go ahead and tap.
4. enter this: min_refresh_rate
5. Save changes. For the second value, enter: 0.1
6. Do this again but instead start with: peak_refresh_rate
7. Save changes
8. enter again, : 0.1
9. Save changes.
That's it! You'll still benefit from adaptive refresh rates when the screen is still and most apps will run in 120Hz regardless of their manifest. Enjoy a smooth Snapchat and everything else!
No.. Google Maps still runs at 60Hz; but rightfully so! It uses a lot of battery as-is.
If you want to undo this, carefully delete the lines we added and reboot the phone.
Screenshot 1: Snapchat 120Hz
Screenshot 2: Native Camera 120Hz
Thanks bossman. On it.
Will this force games like COD Mobile to run in 120pfs?
Kris_b1104 said:
Will this force games like COD Mobile to run in 120pfs?
Click to expand...
Click to collapse
It won't 'force' games to run any higher than they are programmed to. It just allows the screen to go up to 120Hz in most applications that normally wouldn't.
MochaVex said:
It won't 'force' games to run any higher than they are programmed to. It just allows the screen to go up to 120Hz in most applications that normally wouldn't.
Click to expand...
Click to collapse
Thanks, makes sense.
What FPS counter app do you use?
Thank you for this! Does this tweak have an impact on battery life?
Kris_b1104 said:
Will this force games like COD Mobile to run in 120pfs?
Click to expand...
Click to collapse
if you want play COD with 120hz just use [App]Galaxy Max Hz ,
i play on mine s22 with very high graphic quality and force 120hz with this app
herothezero90 said:
Thank you for this! Does this tweak have an impact on battery life?
Click to expand...
Click to collapse
Nothing too noticeable in my experience between stock and forced.
skura91 said:
if you want play COD with 120hz just use [App]Galaxy Max Hz ,
i play on mine s22 with very high graphic quality and force 120hz with this app
Click to expand...
Click to collapse
That's still not 120FPS though, alls it is doing os putting out 120Hz.
Thank you for good article.
Is there any way to fix 90 or 96Hz not 120Hz?
Doesn't work anymore on August update
leonbarroso said:
Doesn't work anymore on August update
Click to expand...
Click to collapse
For my Tab 8, on newest firmware I had to change the min_refresh_rate value to 120. Leaving the peak_refresh_rate at 0.1 Instantly locked to 120.
Actually tested this on my s22+ and the result was me having "grey" screen instead of black in 24hz, just deleted the "peak" and "min" values and restarted and was solved! If anyone getting this, that is the solution.
does it work on s22 ultra in agust 2022 update?
safereg said:
does it work on s22 ultra in agust 2022 update?
Click to expand...
Click to collapse
Re-applied just now and it seems to without any issues.
Any way to use system table or other means to allow adaptive refresh when battery saver is enabled? Even if peak is still 60 fps with battery saver on, seems like it would still improve battery life to have it drop down to 24 or whatever it normally does when there is no motion, though I may be completely wrong.
Why can't Samsung give what we want in the first place? Why don't we have the freedom of choosing what refresh rate our phones runs on, like for ffs
pschoolmeester said:
Any way to use system table or other means to allow adaptive refresh when battery saver is enabled? Even if peak is still 60 fps with battery saver on, seems like it would still improve battery life to have it drop down to 24 or whatever it normally does when there is no motion, though I may be completely wrong.
Click to expand...
Click to collapse
Not that I could find.. They fixed system table modifications for what you're asking for with One UI 4.0's release. Galaxy Max Hz App *might* be able to accomplish this but I'm not entirely sure.
AmmarHaseeb said:
Why can't Samsung give what we want in the first place? Why don't we have the freedom of choosing what refresh rate our phones runs on, like for ffs
Click to expand...
Click to collapse
The Beta Moderator's reasoning was that the phone's hardware couldn't handle the screen running up to 120Hz in every single activity.. part of that is proven incorrect and the rest I can't vouch for because no matter what I do some apps just refuse to go higher than 60Hz.