Related
Previous thread was removed by moderator without any notice after being falsely reported as a wrongly posted thread by a ROM cook.
For kernel developers who care, this is a small quirk that can be patched quite easily. It would be nice if I didn't have to recompile my own kernel because of a small issue like this.
The kernel currently accepts backlight brightness values that are too low in the kernel. There are cases where the screen appears to be off, but is not actually off to Android, as the device will continue to respond to touchscreen events.
Code patch
in board-glacier-panel.c
The workaround is to comment out the entire chunk @ function glacier_shrink_pwm, since the next part should already take care of dimming the panel to its minimum allowed brightness.
Code:
if (brightness < PWM_USER_DIM) {
return 0;
}
Bug description
This issue is documented at least once here
In HTC's code, if glacier_shrink_pwm receives as brightness value < PWM_USER_DIM of 20, it will set the PWM to 0. Effectively, that means any app requesting a brightness < 20 will black out the backlight but not actually turn it off 'properly'
shrink_br ever having a value of 0 appears to be a bug to me, unless someone else can figure out why HTC did this. This piece of code is pretty trivial.
I own the HTC Panache, which is a myTouch4G with a different case.
I have installed the latest TMobileUS Android 2.3.4 ROM, I found that third-party applications can set the backlight brightness down to such a low brightness that it becomes impossible to see anything on the screen.
The device I have contains the SHARP LCD-SH-C2. I am not sure if this same issue affects myTouch4G variants or if it is simply panel type dependent.
This issue may affect other ROMs, if the manufacturer set Android framework minimum brightness is too low. The HTC dev tarball has this bug built into it as well. I think this probably at least affects the HTC Panache in the Canadian market.
This information is intended for kernel developers, because I have yet to find a kernel source who has this patched.
To see if you have this issue, use it is possible to use the following third-party applications to test this:
https://play.google.com/store/apps/details?id=com.deskangel.adjbrightness
https://play.google.com/store/apps/details?id=com.bwx.bequick&hl=en
I am not going to bother releasing a kernel that I wont bother to publish to upload GPL compliant sources for with my slow internet, or else I would have uploaded the binary.
For reference, look at any other shrink pwm logic code on a typical Android device.
I only experience this problem using miui an having the stay awak check in development while on charger screen goes black but its not asleep thank for the patch
Sent from my HTC Glacier using xda premium
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.
I found the volume to be to loud on my device. So I made this module. It just replaces the lineage OS mixer paths tavil file with one that has RX0 decreased from 84 to 70.
Just copy the file to your device, and use the install modules from storage option.
If you want your in-call volume to louder or quieter you can edit the number to your preferences.
I think RX0 is on line 418 in the mixer file.
No guarantee this will not break your phone. I'm just sharing my solution with the community in case someone else has the same issue I did.
This might work on other ROMs and devices, but I have not tested it on any. Post your experiences if you decide to give it a try.
If you decided to edit the file, I suggest changing the value by small increments and testing. I wouldn't increase it by more than 5 at a time. There is a real chance you could damage your speakers if you increase it to much. So don't say you weren't warned.
Mods: If this thread violates something, just delete it.
Credit to the Lineage OS team and Tech Karan for his youtube video on creating modules.
Credits to the developers of the modified GCam project. Please donate to them if possible to keep the development going.
After using it daily on my Pixel 2 XL it is now confirmed working on the Pixel 6.
There are alot of custom options to take that perfect shot available for this modified version, as time passes there will be more releases on the main page on the same site.
Enjoy!
Older version
https://www.celsoazevedo.com/files/android/google-camera/dev-MWP/f/dl23/
Latest version
MWP: Gcam_8.4.300_beta5_MWP
Download Gcam_8.4.300_beta5_MWP by MWP.
www.celsoazevedo.com
Detailed info I found on Google for the app:
What is the lib patcher?
Libpatcher - is a custom setting where you can set all the settings to your liking
Radius Temporal changes the graininess of the image by affecting noise, the higher the image is more blurry and less noise, the lower the more noisy, but more detail
Tone Curve is where you can adjust dark points, white points, shadows, highlights. It is recommended to enable and leave the default values or tweak them (advanced users)
Sharpness allows you to control the sharpness of the image. Zoom in for low-light shots, and zoom out for selfies.
Luminance Noise Reduction is what controls the “graininess” in images caused by high ISO. Decrease it to get more detail at the expense of high noise, or increase it if the noise is unacceptable to you
Color Noise Reduction: Controls color spots. There is usually no need to adjust it as this will not improve the quality, but you can increase it slightly if you see colored spots in the dark. Too much chroma noise can cause a decrease in saturation. Also known as color noise. Be careful with this setting it can mess with the fine details of an image.
Contrast settings allow you to control the contrast of the image. Increase it if you want darker shadows, and decrease it to make it brighter is the general idea. This is again a personal preference
Saturation is what allows you to control the saturation of the image. Increase it if you want more saturated colors in your photos. Obviously decrease if your HDR is getting too saturated. This is again a personal preference
Now there are some advanced settings. These affect the morphological processing. Naturally thats a very basic overview. I took the course while finishing up my engineering degree. It was difficult stuff past the basic level. I wont get into what these settings do beyond a decent generalization.
Warning to all these settings can absolutely have a drastic negative effect on your images. A lot of testing would be necessary by the end user
Luminance noise reduction levels
Level 1 (Detail) changes the photo very slightly, slightly smoothing out small elements in the image.
Level 2 (Rough Surfaces) seriously alters the image by smoothing grain
Level 3 (Edges) doesn’t change much. Smooths edges slightly
Level 4 (Smooth Surfaces) radically alters the image by making it posterized by smoothing out large areas of the same color. Avoid magnification over 1.0
Color noise reduction levels
Level 1 (Detail) fine textures, but the same applies to rough details
Level 2 (Rough surfaces) fine textures, but the same applies to rough details
Level 3 (Edges) Edges are mainly defined by the contrast between one object and another
Level 4 (Smooth Surfaces) Smooth surfaces are generally uniform areas of the image. Like wallpaper with few small details
Tips:
If you notice a certain color of spots on your low light photos. Check its frequency spectrum. Look where its at in the photo and go to the specific wavelet reduction setting and tweak it. See if you can remove it. More often than not these settings are used to improve astrophotography, low light and high detail images.
My sensor has more higher frequency color noise than others. Ive seen some XDA users where they had to turn down denoise. It really all depends on a lot of stuff. Its fun to tweak and squeeze out what you can.
YMMV
I can do most, if not all, of this stuff in GIMP/Photoshop, more easily, with finer control (to include undo), and on a much larger screen
All most of us really want (I can't be the only one) in a "great" camera app is total control of:
1. Shutter speed
2. "ISO"
3. Aperture
4. Lens selection
just like my Galaxy S8's "pro mode"
Everything else can be "fixed" in post.
-But then I'm just an old guy with camera and a darkroom
biTToe said:
I can do most, if not all, of this stuff in GIMP/Photoshop, more easily, with finer control (to include undo), and on a much larger screen
All most of us really want (I can't be the only one) in a "great" camera app is total control of:
1. Shutter speed
2. "ISO"
3. Aperture
4. Lens selection
just like my Galaxy S8's "pro mode"
Everything else can be "fixed" in post.
-But then I'm just an old guy with camera and a darkroom
Click to expand...
Click to collapse
Yeah I totally get that, photo editing software is better on a computer and is more fine tuned.
This is an easy way to get more customized results. I've seen way too many complaints about the built in app being too restricted and plain.
This adds additional functionality and is my go to application when taking photos for years now.
legend221 said:
Credits to the developers of the modified GCam project. Please donate to them if possible to keep the development going.
After using it daily on my Pixel 2 XL it is now confirmed working on the Pixel 6.
There are alot of custom options to take that perfect shot available for this modified version, as time passes there will be more releases on the main page on the same site.
Enjoy!
MWP: Gcam_8.4.300.v1_beta3
Download Gcam_8.4.300.v1_beta3 by MWP.
www.celsoazevedo.com
Detailed info I found on Google for the app and recommended settings:
What is the lib patcher?
Libpatcher - is a custom setting where you can set all the settings to your liking
Radius Temporal changes the graininess of the image by affecting noise, the higher the image is more blurry and less noise, the lower the more noisy, but more detail
Tone Curve is where you can adjust dark points, white points, shadows, highlights. It is recommended to enable and leave the default values or tweak them (advanced users)
Sharpness allows you to control the sharpness of the image. Zoom in for low-light shots, and zoom out for selfies.
Luminance Noise Reduction is what controls the “graininess” in images caused by high ISO. Decrease it to get more detail at the expense of high noise, or increase it if the noise is unacceptable to you
Color Noise Reduction: Controls color spots. There is usually no need to adjust it as this will not improve the quality, but you can increase it slightly if you see colored spots in the dark. Too much chroma noise can cause a decrease in saturation. Also known as color noise. Be careful with this setting it can mess with the fine details of an image.
Contrast settings allow you to control the contrast of the image. Increase it if you want darker shadows, and decrease it to make it brighter is the general idea. This is again a personal preference
Saturation is what allows you to control the saturation of the image. Increase it if you want more saturated colors in your photos. Obviously decrease if your HDR is getting too saturated. This is again a personal preference
Now there are some advanced settings. These affect the morphological processing. Naturally thats a very basic overview. I took the course while finishing up my engineering degree. It was difficult stuff past the basic level. I wont get into what these settings do beyond a decent generalization.
Warning to all these settings can absolutely have a drastic negative effect on your images. A lot of testing would be necessary by the end user
Luminance noise reduction levels
Level 1 (Detail) changes the photo very slightly, slightly smoothing out small elements in the image.
Level 2 (Rough Surfaces) seriously alters the image by smoothing grain
Level 3 (Edges) doesn’t change much. Smooths edges slightly
Level 4 (Smooth Surfaces) radically alters the image by making it posterized by smoothing out large areas of the same color. Avoid magnification over 1.0
Color noise reduction levels
Level 1 (Detail) fine textures, but the same applies to rough details
Level 2 (Rough surfaces) fine textures, but the same applies to rough details
Level 3 (Edges) Edges are mainly defined by the contrast between one object and another
Level 4 (Smooth Surfaces) Smooth surfaces are generally uniform areas of the image. Like wallpaper with few small details
My Settings
Now I have done A LOT of testing on my phone, with my case (affects light angles coming in slightly) and just about everything I can to nail these in for my device and my tastes so please dont just copy and paste. This is more of an informative post.
Libpatcher Switches:
Force System Noise Model (I tweaked the tweaked one but I cant post that code (license issues)) ON
Disable Dehave ON
Sharpness: 1.13
Saturation: 1.21
Global Chroma Denoise: Set to wavelet
Global Luma Denoise: Set to wavelet
Wavelet Luma Denoise Settings:
Level 1 - 0.875
Level 2 - 0.875
Level 3 - 1.0
Level 4 - 1.125
Wavelet Chroma Low Frequency Denoise Settings: (556 THz - 792 THz) 89
Level 1 - 1.0
Level 2 -1.0
Level 3 - 1.1
Level 4 - 1.2
Wavelet Chroma High Frequency Denoise Settings: (403 THz - 555 THz) 89
Level 1 - 0.875
Level 2 - 1.0
Level 3 - 1.0
Level 4 - 1.3
Those work far better for me and ive noticed my pictures have less sports
Tips:
If you notice a certain color of spots on your low light photos. Check its frequency spectrum. Look where its at in the photo and go to the specific wavelet reduction setting and tweak it. See if you can remove it. More often than not these settings are used to improve astrophotography, low light and high detail images.
My sensor has more higher frequency color noise than others. Ive seen some XDA users where they had to turn down denoise. It really all depends on a lot of stuff. Its fun to tweak and squeeze out what you can.
YMMV
Will post occasional pics displaying some of the modded apps performance on occasion
Why didnt your wavelet settings work for me
Factors that affect settings
Your phone
When it was made
The chip itself
The silicon in your sensor
Ambient weather conditions
The image processing firmware on the Pixel Visual Core
Other properties of silicon unique and intrinsic to your device
FAQ
Why are your colors listed as frequencies?
Light is an electromagnetic phenomenon and as an RF engineer its easier for me to refer to spectra as a frequency but one could easily refer to it in wavelengths or color (but color wont be accurate as thats up to perception)
What are wavelets?
A wavelet is how we define a center frequency and some deviation. We use wavelets because a color is not just one frequency its a range see here : Spectral color - Wikipedia 10 Its also an entire subset of mathematics used by anyone who works with the spectrum (i.e RF engineers, optical engineers (fiber stuff), biomedical engineers). They are helpful because we can take the average of a color spectrum (say blues) and convolve it with the signal to find the center frequency of blue or the blues in a subset (image). It basically the magic behind the IM processing math.
Just tried a sample of my night time “light bleed” mode and its okay. It still need more tweaking but heres an example of what tweaking your denoise settings can do. The image is far better than a stand night photograph (even with some longer exposure)
Keep in mind you wont remove all the noise. In fact it sometimes takes noise to remove or smooth noise (dithering). Dithering is a process where we add a bit of noise to a data set in an attempt to constructively perturb the signals we want to convolve, isolate and amplify over the average.
Click to expand...
Click to collapse
See the problem with copying stuff off Google without knowing what your doing is that you have added all this and the cam doesn't have the majority of it so you are misleading users dude. You sure you have mentioned the correct cam version?
enerGy said:
See the problem with copying stuff off Google without knowing what your doing is that you have added all this and the cam doesn't have the majority of it so you are misleading users dude. You sure you have mentioned the correct cam version?
Click to expand...
Click to collapse
You can try it if you'd like or keep using the built in one. I've been using this version on my Pixel 6.
There are also other builds on the same site.
Honestly I don't even use the stock one that came with the phone. Not too many options or settings to adjust vs this Mod.
These guys have been doing this for years I've personally used it on my Pixel 2 XL since I can remember.
I'm very confident they have the knowledge and experience to release this Mod to the public.
legend221 said:
You can try it if you'd like or keep using the built in one. I've been using this version on my Pixel 6.
There are also other builds on the same site.
Honestly I don't even use the stock one that came with the phone. Not too many options or settings to adjust vs this Mod.
These guys have been doing this for years I've personally used it on my Pixel 2 XL since I can remember.
I'm very confident they have the knowledge and experience to release this Mod to the public.
Click to expand...
Click to collapse
What do you mean? I didn't say anything about the guy who builds it or him not having knowledge lol, I know him. You just replied with something totally different to what was questioned dude, doesn't make sense. Many of the options and values you gave are not in this cam as you can see below thus why I'm asking have you posted the correct version. Also I'm no noob as you might be suggesting lol I've plenty of experience with GCam on many many devices creating configs for personal use and for public.
enerGy said:
What do you mean? I didn't say anything about the guy who builds it or him not having knowledge lol, I know him. You just replied with something totally different to what was questioned dude, doesn't make sense. Many of the options and values you gave are not in this cam as you can see below thus why I'm asking have you posted the correct version. Also I'm no noob as you might be suggesting lol I've plenty of experience with GCam on many many devices creating configs for personal use and for public.
Click to expand...
Click to collapse
We are both Senior Members I know. I should edit the posting as the settings were taken from another source online.
Let the users try it and keep using it if they like it. Let him know he is an amazing guy and I hope he gets alot of well deserved donations.
Thank you for your work on the configs as well.
Hi, I strongly recomend last NOT BETA version of this great app, so Gcam_8.3.252_V2.0c_MWP (https://www.celsoazevedo.com/files/android/google-camera/dev-MWP/) Gcam_8.3.252_V2.0c_MWP
novaq72 said:
Hi, I strongly recomend last NOT BETA version of this great app, so Gcam_8.3.252_V2.0c_MWP (https://www.celsoazevedo.com/files/android/google-camera/dev-MWP/) Gcam_8.3.252_V2.0c_MWP
Click to expand...
Click to collapse
Thank you @novaq72
I tried out the last stable version and my P6 was not saving the pictures. I have been running without problems on 8.4.300 v1 beta3.
If anyone has any issue from the OP definitely try out the one above.
It's a pity, I don't have a problem with not saving pictures (P6P). But I use a gallery other than Google Photos, so maybe that's why. The stable version by MWP has a lot more settings options than the beta version, I think. But I use the MWP app mainly because of the names of the photos, which the built-in version has, politely speaking, 'awkward'.
legend221 said:
Thank you @novaq72
I tried out the last stable version and my P6 was not saving the pictures. I have been running without problems on 8.4.300 v1 beta3.
If anyone has any issue from the OP definitely try out the one above.
Click to expand...
Click to collapse
It's a pity, I don't have a problem with not saving pictures (P6P). But I use a gallery other than Google Photos, so maybe that's why. The stable version by MWP has a lot more settings options than the beta version, I think. But I use the MWP app mainly because of the names of the photos, which the built-in version has, politely speaking, 'awkward'.
Can you share the config file?
nchmaster said:
Can you share the config file?
Click to expand...
Click to collapse
I'm sorry unless it's on the official website I don't have it.
The app is working great without any additional files at the moment.
Google Camera Mod 8.4.300 v1 beta 5 by MWP
===============================
Changelog from previous version, plus:
1. Replacing Libpatcher with Rampatcher. Thanks Eszdman & Hasli.
2. Rearrange the settings menu.
3. Enable all fps selection in video mode.
4. Added Super res zoom / merge method.
5. Added max shutter speed limitation.
6. Added developer settings help.
7. And more
NOTE: All the previous configs (.xml) can't be use in this version.
MWP: Gcam_8.4.300_beta5_MWP
Download Gcam_8.4.300_beta5_MWP by MWP.
www.celsoazevedo.com
The download link on the site seems to be dead.
Fixed.
Google Camera Mod 8.4.300 beta 6 by MWP
==============================
Changelog from previous version, plus:
Minor changelog:
1. New libs ( xHDR & NoiC )
2. Optimized some code and added some parameters to libpatcher
NOTE: Clear app data & cache before use.
MWP: Gcam_8.4.300_beta6_MWP
Download Gcam_8.4.300_beta6_MWP by MWP.
www.celsoazevedo.com
Thanks for this. But the currently google camera in the store is 8.6?
Utini said:
Thanks for this. But the currently google camera in the store is 8.6?
Click to expand...
Click to collapse
Different developers use different Google Camera versions. Let's say it this way.. Latest is not always the greatest
Dayuser said:
Different developers use different Google Camera versions. Let's say it this way.. Latest is not always the greatest
Click to expand...
Click to collapse
Thanks! If i understand correctly the this does better pictures than the stock gcam? No .xml needed?
Utini said:
Thanks! If i understand correctly the this does better pictures than the stock gcam? No .xml needed?
Click to expand...
Click to collapse
It depends what you like. Every gcam versions with stock settings is little different but it is better use xml if somebody has created xml.