• General
  • [Feature Request] PWM display options to reduce screen flickering

Hello,

I'm using GrapheneOS since long time and love it together with my history of Pixel phones.
Since I and many people have issues with OLED screen flickering (based on Samsung panels used and their default calibration), I had many issues with Pixel phones since they use low PWM rate of 240hz. This value is very low and generates eye strain and headaches to many users like me. Samsung and Google decided to not care about PWM, if we look at chinese phone vendors like Honor or Vivo they use between 2000 and 5000 Hz, these values do not cause any health issues.

PWM is used to reduce screen brightness, bad implementations use low refresh values and generate screen flickering.
Even with Pixel 9 Series (9, 9 Pro, 9 Pro XL, 9 Pro Fold) it's not going to change, since the whole Pixel 9 line up still uses 240hz for PWM. So the whole OLED Pixel line-up is affected since many years now and I'm embarassed it's still the case with new models.

Because of that I finally hope the issue can be fixed by GrapheneOS team.
For Pixel 8 Pro for example there is an easy fix, which can improve the PWM rate from 240hz up to 4800hz:
https://www.androidcentral.com/phones/google-pixel-8-pro-display-upgrade

Right now the fix needs root access sadly, but if it could be implemented natively to GrapheneOS root access would not be needed. It would be very nice to have this as an added native feature in future GrapheneOS releases. For sure allowed PWM values are model dependent, but probably this can be respected in the software. Users could be able to choose their prefered PWM value in the Display settings whenonly supported PWM rates are shown.

The fix is a single line of code for Pixel 8 Pro
Technically the fix uses following method:
Photo

Hope this feature request is interesting for the GrapheneOS team and possible to realize.

Since I can't edit my post anymore, the technical implementation is provided below.

The fix is a single line of code for Pixel 8 Pro
echo 0x05,0x43,0x43,0x03 > /sys/module/panel_google_hk3/parameters/freq_cmd

The first 0x05 section is the PWM rate multiplier. Testing with several folks shows that the highest rate some phones support is 0x07, which equates to 3840Hz PWM dimming. You can always experiment with different values if you want. Just make sure to turn the display off and on for the new rate to take effect.

  • de0u replied to this.

    Sindbad The fix is a single line of code for Pixel 8 Pro.

    Despite the article headline, whatever is being done is not "a single line of code", because one of the previous steps is installing a custom kernel!

    It might be productive to experiment with that setup. For example, aside from the green tint, are there battery-life implications? System crashes? Premature screen aging? RF emissions out of range?

    As described this does not sound line something I would expect the GrapheneOS project to ship in the near future. However, interested parties might cooperate to hire an Android developer to make a custom build of GrapheneOS including the relevant code so people could try it.

    Please note that I do not speak for the GrapheneOS project.

    The relevant code is a single line of code, with adjustable values to change the PWM rate.
    Applying the method right now requires root and a custom kernel, but this would not be the case anymore if GrapheneOS would be able to integrate the function as a native software feature.

    Official source with more details:
    https://xdaforums.com/t/a-mod-on-pwm-frequency.4683727/

    • de0u replied to this.

      Sindbad The relevant code is a single line of code, with adjustable values to change the PWM rate.

      That is not the "relevant code", if it absolutely requires an unknown amount of code being present in the kernel, which it does. Repeating the click-bait claim that the echo command that configures the code is the code seems unlikely to convince anybody in a decision-making role to invest time looking into this.

      Sindbad Applying the method right now requires root and a custom kernel, but this would not be the case anymore if GrapheneOS would be able to integrate the function as a native software feature.

      Correct. And it is possible that a GrapheneOS developer would decide to spend time on that based on this forum thread. It is also possible that would not happen. Something that could increase the likelihood of it happening would be a community contribution, such as an Android developer who isn't a member of the GrapheneOS developer team reading the code, porting it to GrapheneOS, and trying it.

      To be clear, I am absolutely not telling anybody what to do. That said, I would advise staying away from the "one line of code" framing, because the people who would need to evaluate and support the actual code will know better.

      Do you have a link to the relevant kernel patch?

        aw22 The XDA article linked above by Sindbad contains a GitHub link to a branch with 8 commits at present. That may or may not apply cleanly to a GrapheneOS tree.

        In addition to caveats about color infidelity and potential lockups, note the disclaimer about possible hardware damage. Personally I have no idea how likely that might be, but I could imagine longevity issues.

        aw22 The fact this solution is described as "a single line of code" is a misnomer. The single line of code in the article is writing values to a parameter of the modified kernel driver of the display panel controller that is implemented in this commit. Presumably it is signaled to the display panel controller and otherwise opaque to the host.

        Accessing the kernel module parameter as described in the article involves root access but an implementation integrated into the operating system could be written. For integration it is a question of the project how such "tunables" should be exposed to the user without needing root.

        I assume the values in question were derived through knowledge of the existing values and experimentation. As far as I know no data-sheets for the display panel controller of this detail have ever surfaced publicly.

        https://github.com/GrapheneOS/os-issue-tracker/issues/3850

        Came across this ticket on the GrapheneOS issue tracker. Extremely disappointed by the response. It is ok to stare at a screen with aggressive flickering even when it triggers a physical manifestation of medical symptoms? And it can not be solved by any current medical treatment!

        The display industry is rather secretive. As far as I am aware no one from Samsung or other company has joined in to either justify the decision or work towards a solution.

          Elephant

          For me it's like erasing flash memory with zeros for privacy - it would also affect the chip's lifespan and failure rate, and I believe it's up to the user to accept the risk, if any.

          I do not think using flawed analogies is productive towards this cause either. Wear leveling going to get ya ;-)

          • Edited

          @Sindbad while the following won't help regarding GrapheneOS or Pixel devices, this is exactly what Daylight is doing with their flicker-free and no-blue light DC-1 tablet. Keep in mind, this is a health-oriented device designed for such people, but Daylight is taking on a hugely important topic and doing some seriously cool stuff with their display technology.

          Seth for Privacy (GrapheneOS advocate) reviewed his unit here:
          https://sethforprivacy.com/posts/daylight-dc1-magical-imperfection/

          If anyone wants to nerd out further on this stuff, Dr. Jack Kruse is generally regarded as the go-to source for all things circadian biology and how it pertains to the technology we use.

          I also would greatly appreciate improved PWM if in any way it was a simple addition to the (already heavily modified custom) grapheneos kernel.