Related
We have a fix
Please read this post (and Thanks Milaq for the fix!!) and follow the instructions.
[*]Also, can someone test custom auto brightness levels too please?
I have made a ClockWorkMod flashable version of the fix in this post. This should cover almost all ROMs, irrespective of how the device is named in build.prop (leo, htcleo, bravo, qsd8k).
Original Post:
UPDATE: Thanks to Looki75, we have a workaround using Tasker to have custom auto-brightness levels with the flashing LED libraries here. Please go through his post and give your feedback!
I am rewriting the whole post, based on what I realized/ learnt today
We currently two lights libraries for to our phone:
lights.htcleo.so - this file has working auto-brightness and flashing LED notifications - but custom auto-brightness settings do not work (more on this a bit later)
lights.qsd8k.s0 - this file has working auto-brightness and custom auto-brightness levels, but LED notifications do not flash
Custom auto-brightness settings
What is it?
This is a setting/ feature in CM7 ROMs, not sure if MIUI has it or not (Users, please confirm if you have custom auto-brightness settings in non-CM7 based ROMs)
In a pitch dark room, the screen's brightness chosen by auto-brightness setting may be higher than required. With custom auto-brightness, the level of brightness the phone uses for a specific amount of light can be configured - the biggest benefit being higher battery life. Please read this post by @Dorimanx for custom auto-brightness levels.
How do I know if I have it or not?
You do not have the lights library that is compatible with custom auto-brightness levels if:
Your LED Notifications work (Except HeirOS kernels)
If you have something similar to this in your logcat:
20:50:43.090 Error lights 180 ***: value=90 (Mode=1)
20:50:43.090 Error lights 180 ***: value=91 (Mode=1)
20:50:43.090 Error lights 180 ***: value=92 (Mode=1)
20:50:43.090 Error lights 180 ***: value=94 (Mode=1)
Click to expand...
Click to collapse
On the other hand, you have it if
Your LED does not flash
Your screen will dim for several seconds (5~10seconds) before timing out
You do not see the errors I had quoted above in your logcat
So what is the point of this thread?
I had tried several Kernel combinations (and libaudio.so, but that does not matter in this issue) while trying to figure out the No Sound/ BT Voice Command/ libaudio.so issues, and found out that even if I have lights.qsd8k.so, which enables custom auto-brightness levels, LED Notifications flash with HeirOS 1.7.5 Kernel - they flash in amber and green alternatively. This gave me a hope that
This is something to do with the kernel (I used Tytung's initrd.gz, so it is not from there...)
This could be fixed easily with all our kernels, because HeirOS has already done it!
So What Next?
Anyone using any of the HeirOS kernels see what library you have (/system/lib/hw), and please use the lights.qsd8k.so if it is not there, deleting lights.htcleo.so while at it (it is available in the Mirrors used by @Dorimanx), and confirm if you concur with my observations - please mention the kernel version and the name of the lights library in your feedback.
Once we have that confirmed, we can request HeirOS to let us know the secret ingredient (or someone intelligent enough to look through the source codes can find it and post the diff/ findings).
This is not a critical/ experience-affecting issue, but rather something that is now "broken" and can be fixed without much ado!! I am sorry for not being clear earlier, a little bit of Rum cleared things up for me
Lets now restart this discussion!!!
It is people like you that are going to make our phone as if it came with android when we bought it! I know you are not the one doing the coding but with all your support, your don't give up attitude, and your connections you get the job done. Thank you for all your determination.
Sent from my HTC HD2 using XDA App
hopefully the next thread for collaboration work that will become one of it's kind in hd2 android history. thx for your dedication and all the testing that you do! thanks to all the devs making our hd2 improving everyday.
I have posted a request in HeirOS' kernel thread, meanwhile can those who use earlier versions (1.7.2 or so) confirm if they have working LED Notifications when you use a working auto-brightness configuration please?
If so, I think we can trawl the source code posted on the first post of HeirOS kernel thread...
ph03n!x said:
We currently have to choose between a working auto-brightness setting, or a working flashing LED notification in most configurations/ kernals....
Click to expand...
Click to collapse
Had never problems with auto brightness and my last kernel with a non working LED notification is older than around a half year. But I tried only MDJ, Tytungs and Raf's kernel. Green and orange LED are working perfect with these.
What problems do you have with auto brightness? Not working or the false brightness for the actual light?
Only outdoor at sunshine the auto brightness sometimes didn't choose the maximum brightness, than I set manual to max.
Nixda99 said:
Had never problems with auto brightness and my last kernel with a non working LED notification is older than around a half year. But I tried only MDJ, Tytungs and Raf's kernel. Green and orange LED are working perfect with these.
What problems do you have with auto brightness? Not working or the false brightness for the actual light?
Only outdoor at sunshine the auto brightness sometimes didn't choose the maximum brightness, than I set manual to max.
Click to expand...
Click to collapse
The auto-brightness / LED notifications are from /system/lib/hw/lights.htcleo.so (or lights.qsd8k.so).
In our case if your ROM's chef chose to have a working LED Notification configuration, auto-brightness will not work - the display will have a fixed brightness irrespective of the surroundings, and will not dim before fading out.
If you choose working Auto Brightness, the screen will maintain ambient lighting, but when have a missed call or SMS or email or chat, the LED stays on and does not flash.
That said, what kernel are you using? And can you check your logcat right from system boot (using QtADB?) and let us know if you see any errors?
ph03n!x said:
The auto-brightness / LED notifications are from /system/lib/hw/lights.htcleo.so (or lights.qsd8k.so).
In our case if your ROM's chef chose to have a working LED Notification configuration, auto-brightness will not work - the display will have a fixed brightness irrespective of the surroundings, and will not dim before fading out.
Click to expand...
Click to collapse
Yeah...
Typhoon included Led blinking, i always replace it with lights.qsd8k.so with auto-brightness, i dont care about Led blinking too much, more interesting good working auto-brightness
Install led me know from the market and you will have both working fine.That is what i do in dorimanx rom which has auto brightness enabled by default.
eseregin said:
Yeah...
Typhoon included Led blinking, i always replace it with lights.qsd8k.so with auto-brightness, i dont care about Led blinking too much, more interesting good working auto-brightness
Click to expand...
Click to collapse
Sent from my HD2 using XDA App
ph03n!x said:
The auto-brightness / LED notifications are from /system/lib/hw/lights.htcleo.so (or lights.qsd8k.so).
In our case if your ROM's chef chose to have a working LED Notification configuration, auto-brightness will not work - the display will have a fixed brightness irrespective of the surroundings, and will not dim before fading out.
If you choose working Auto Brightness, the screen will maintain ambient lighting, but when have a missed call or SMS or email or chat, the LED stays on and does not flash.
That said, what kernel are you using? And can you check your logcat right from system boot (using QtADB?) and let us know if you see any errors?
Click to expand...
Click to collapse
If I remember it correctly, the working LED Notification (i.e. No fading out feature) of lights.htcleo.so in my GB ROM is from Gpc.
Moreover I think that the developer of LedMeKnow app, which is free by the way, may point out to the developers what to change in order to have both auto brightness and led blinking working out of the box for hd2s
karapialis said:
Install led me know from the market and you will have both working fine.That is what i do in dorimanx rom which has auto brightness enabled by default.
Sent from my HD2 using XDA App
Click to expand...
Click to collapse
Sent from my HD2 using XDA App
leds and auto brightness work perfectley if you use the lights file from iamgpc. So I dont see the problem. Secondly this problem is hard to catch I can remember that Letama and gauner1986 tried to solve this problem but at the end they gave up.
jan-willem3 said:
leds and auto brightness work perfectley if you use the lights file from iamgpc. So I dont see the problem. Secondly this problem is hard to catch I can remember that Letama and gauner1986 tried to solve this problem but at the end they gave up.
Click to expand...
Click to collapse
Yes, manual brightness works in GPC's lights.htcleo.so, but auto-brightness does not.
I found the HeirOS has fixed this (though not documented) in 1.7.5 (not tested earlier versions)...
ph03n!x said:
We currently have to choose between a working auto-brightness setting, or a working flashing LED notification in most configurations/ kernals.
I am saying "most" because in my quest to fix the No Sound/ BT Voice Command/ libaudio.so issues, I tested various kernels and configurations, and found that with HeirOS 1.7.5 kernel, I have a working auto-brightness WITH flashing LED notifications. The notifications actually flash amber and green.
So looks like this is something that we can fix easier than the close to 5 weeks spent on the No Sound bug
HeirOS, please share your thoughts/ inputs for the benefit of all of us!!
This is not a critical/ experience-affecting issue, but rather something that is now "broken" and can be fixed without much ado!!
My explanation / understanding of the LED Notification vs. Auto Brightness issue- correct me if required
Click to expand...
Click to collapse
Here is a well-known solution for auto-brightness + flashing LED:
karapialis said:
Install led me know from the market and you will have both working fine
Click to expand...
Click to collapse
Like I said earlier, while fixing it natively is a good-to-have solution, and not a deal breaker for almost all of us. But still having it fixed surely feels good, doesn't it?!!
karapialis said:
Install led me know from the market and you will have both working fine
Click to expand...
Click to collapse
Updated the first post
karapialis said:
Moreover I think that the developer of LedMeKnow app, which is free by the way, may point out to the developers what to change in order to have both auto brightness and led blinking working out of the box for hd2s
Sent from my HD2 using XDA App
Click to expand...
Click to collapse
LED Me Know eats up battery while flashing notification. When its flashing LED, the battery drain is more than 100mAh. Though I haven't used the application in a long time, but I remember previously it used to do that...I wonder if its changed now..
I actually prefer a static LED with working auto brightness.
Its very obvious without staring at my phone whether I have a new text, missed call, or otherwise. I tend to miss the blinking since its 8 seconds apart.
(know it can be configured to 3 seconds, but still)
Sent from my HTC HD2 using Tapatalk
ph03n!x said:
Yes, manual brightness works in GPC's lights.htcleo.so, but auto-brightness does not.
I found the HeirOS has fixed this (though not documented) in 1.7.5 (not tested earlier versions)...
Click to expand...
Click to collapse
Auto brightness works fine here.
In HeirOS 1.8 kernel i have led working and i do notice that when its really dark the screen will get bright and when its super sunny it gets darker so i believe auto brightness + led works fine in his new test kernel btw i am on sense gb rom.
Vice versa
In HeirOS 1.8 kernel i have led working and i do notice that when its really dark the screen will get bright and when its super sunny it gets darker so i believe auto brightness + led works fine in his new test kernel btw i am on sense gb rom.
Click to expand...
Click to collapse
Sent from my HD2 using XDA App
Auto brightness with flashing LED notification works perfectly in Tytung's rom and kernel.
Today is the very first time ever for me to root an android device and thank God it run perfectly.
Now i am using AIC kernel for V500 4.4.2 stock ROM. (http://forum.xda-developers.com/showthread.php?t=2741405)
Gamma correction in it really improved screen and picture quality. (plus 8000 antutu point increase bonus)
Before, i can barely see anything in Bloodborne trailer video. (http://www.youtube.com/watch?v=G203e1HhixY)
Since i cant post in development thread, i hope i can find answers to the followings:
Is it possible to further improve gamma in the future?
Even though currently gamma is improved, but the brightness level issue still persist. Is it hardware or software issue?
Is there any possibility for brightness level improvement in the near future (kernel) update?
All in all, i really like my G Pad and really hope for the possibility to receive screen improvement update in the near future.
uchihamonkey said:
Today is the very first time ever for me to root an android device and thank God it run perfectly.
Now i am using AIC kernel for V500 4.4.2 stock ROM. (http://forum.xda-developers.com/showthread.php?t=2741405)
Gamma correction in it really improved screen and picture quality. (plus 8000 antutu point increase bonus)
Before, i can barely see anything in Bloodborne trailer video. (http://www.youtube.com/watch?v=G203e1HhixY)
Since i cant post in development thread, i hope i can find answers to the followings:
Is it possible to further improve gamma in the future?
Even though currently gamma is improved, but the brightness level issue still persist. Is it hardware or software issue?
Is there any possibility for brightness level improvement in the near future (kernel) update?
All in all, i really like my G Pad and really hope for the possibility to receive screen improvement update in the near future.
Click to expand...
Click to collapse
I heard a week or so ago through the grapevine of a version 20d coming out pretty soon. I have held off making any other changes to the AIC kernel until I see what LG did(no sense reinventing the wheel).
What brightness issue would you like changed? I know in general people think the Gpad screen is dark, but some of the AIC kernel users think the lowest brightness is too bright as well.
I think the screen is pretty bright at 100%, so for me it's a software issue. That's in 2 places, the kernel backlight driver, and the ROM brightness(think brightness slider).
aicjofs said:
I heard a week or so ago through the grapevine of a version 20d coming out pretty soon. I have held off making any other changes to the AIC kernel until I see what LG did(no sense reinventing the wheel).
What brightness issue would you like changed? I know in general people think the Gpad screen is dark, but some of the AIC kernel users think the lowest brightness is too bright as well.
I think the screen is pretty bright at 100%, so for me it's a software issue. That's in 2 places, the kernel backlight driver, and the ROM brightness(think brightness slider).
Click to expand...
Click to collapse
Tks for the reply and also thank you very much for the kernel, it really is helping a lot!
Rather than issue, i should have worded it as G Pad having a relatively low brightness level/dim display.
Compare to my nexus 7 1st gen, G Pad at 70% brightness level still not as bright as nexus at 30%.
Actually i dont really mind it, 70-80% G Pad brightness level is my sweet spot.
However, it would be great if the number is 30% rather than 70% (i am just feeling paranoid of having big number for a display setting).
I also realized that colours (might be) a bit off, especially red that looks orange-ish.
In general display seems lean toward yellow (yellowish-white).
Wonder if this is a common thing for all unit?
Hopefully it is just a matter of colours calibration that can be solved through software update not a hardware characteristic.
I tried Screen Adjuster and added more blue and red, but i just cant seems to find the proper setting to create a whiter white or redder red...
All in all, it is nice to hear version 20d may be coming soon.
Hopefully LG will address all these screen related things.
Also, really look forward to your another great work, especially when LG get it all wrong again this time
aicjofs said:
I heard a week or so ago through the grapevine of a version 20d coming out pretty soon. I have held off making any other changes to the AIC kernel until I see what LG did(no sense reinventing the wheel).
What brightness issue would you like changed? I know in general people think the Gpad screen is dark, but some of the AIC kernel users think the lowest brightness is too bright as well.
I think the screen is pretty bright at 100%, so for me it's a software issue. That's in 2 places, the kernel backlight driver, and the ROM brightness(think brightness slider).
Click to expand...
Click to collapse
It would be great if you could add row scheduler when you next update your kernel.
Thanks in advance rich ?
Sent from my LG-V500 using XDA Premium HD app
uchihamonkey said:
Tks for the reply and also thank you very much for the kernel, it really is helping a lot!
Rather than issue, i should have worded it as G Pad having a relatively low brightness level/dim display.
Compare to my nexus 7 1st gen, G Pad at 70% brightness level still not as bright as nexus at 30%.
Actually i dont really mind it, 70-80% G Pad brightness level is my sweet spot.
However, it would be great if the number is 30% rather than 70% (i am just feeling paranoid of having big number for a display setting).
I also realized that colours (might be) a bit off, especially red that looks orange-ish.
In general display seems lean toward yellow (yellowish-white).
Wonder if this is a common thing for all unit?
Hopefully it is just a matter of colours calibration that can be solved through software update not a hardware characteristic.
I tried Screen Adjuster and added more blue and red, but i just cant seems to find the proper setting to create a whiter white or redder red...
All in all, it is nice to hear version 20d may be coming soon.
Hopefully LG will address all these screen related things.
Also, really look forward to your another great work, especially when LG get it all wrong again this time
Click to expand...
Click to collapse
You can use Faux Clock or System Tuner to adjust the color temp and gamma.
meanoc said:
You can use Faux Clock or System Tuner to adjust the color temp and gamma.
Click to expand...
Click to collapse
Really...?
In that Kernel thread it states....
Add Faux Display interface (gamma control seems broken)
so does the Faux app control the gamma, even though aicjofs had noted that it seemed to be broken...?
vimesUK said:
Really...?
In that Kernel thread it states....
Add Faux Display interface (gamma control seems broken)
so does the Faux app control the gamma, even though aicjofs had noted that it seemed to be broken...?
Click to expand...
Click to collapse
It works for me?
meanoc said:
You can use Faux Clock or System Tuner to adjust the color temp and gamma.
Click to expand...
Click to collapse
Pardon me but where can i find this Faux Clock and System Tuner?
Do you have any preferred setting for optimum screen (colour) performance?
uchihamonkey said:
Pardon me but where can i find this Faux Clock and System Tuner?
Do you have any preferred setting for optimum screen (colour) performance?
Click to expand...
Click to collapse
You can find them here https://play.google.com/store/apps/details?id=com.teamkang.fauxclock and https://play.google.com/store/apps/details?id=ccc71.pmw.pro . Your best bet is to either use a calibration tool or just adjust it to your eyes.
Dear All,
I´ve managed to build a CM 12.1 with nfs support. Why 12.1? Well, for my D855, that was the only branch I could get working when building a kernel in Ubuntu, using the downloadable snapshot at CM´s site. The nighty´s would give me errors of different kinds during the building process, so the files on the phone needed when building are probably not the exact required version that match with the repo you can download in terminal mode.
Anyway, my experience with marshmellow is that the phone gets so hot that it turns itself off - another good reason to stay with 12.1.
My phone however still gets hot, which happens when using it with my VR headset to watch UHD clips. After 5 mins of watching, it dims down a bit. Then a few mins later a bit more, and so on until it looks like I´m staring at the screen through old cheap shades.
I´ve already disabled automatic brightness control, tried apps which claim to keep the brightness at the desired strength (Lux, the app is called), an app that´s ment to keep the screen always on (Always Awake), an app claiming to patch this exact bug, flashed a hack that´ll throttle only above 70 C. None of this helped. What I do know is that in the secret menu of stock firmware, there´s an option called Thermal Daemon Mitigation OFF, but I can´t access the secret menu through CM - only CM´s secret menu, that doesn´t have this option. Enabling this is said to cope with the problem.
There´s also a file named thermanager.xml in system/etc, which looks like something which can be modified to meet my requirements, but I´m not sure.
Finally, my least prefered option is to install a thermal pad on the SoC, but although I´m experienced with hardware, it´s on desktop level - not with such tiny things as a mobile.
So please, could someone help out here? Is there a way to rebuild the kernel with the stock secret menu or amendments to the throttling? Is there a way for me to get into the stock secret menu in CM?
Other ideas?
PS: I´m posting here because if there´s a way to get Thermal Daemon Mitigation OFF option related parameters set when building kernel in menuconfig, then it´s related to this sub forum.
PPS: Edited thermanager so all brightness values are 255, this seems to fix the problem!
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.