PWM and flicker-free LCD displays on Librem notebooks?

Hardware
1

And important aspect for me is eye-strain caused by the display, please can you MEASURE if the LCD panels in your notebooks are flicker-free? (not the “flicker bug” mentioned here, but PWM-caused flicker)

PWM-pulse width modulation is used on some LCDs for screen dimming and it’s problematic and can cause eye-strain for some. I’d like to know how Librem notebooks fare in this aspect (the LCD should either not use PWM at all, or use it at very high frequencies, so it’s not visible).

2 Likes
2

I looked into this topic in some depth recently, as I was suffering from headaches (which turned out to be unrelated to PWM).

I don’t have access to a Librem notebook to test with, but I do know that Intel integrated graphics have baked-in support for screen-dimming using PWM. So, it seems likely that notebooks like the Librems, which use Intel graphics, will use the built-in PWM. Doing it another way would probably involve costly non-standard hardware. I’d wager that most of the PWM-free notebooks available today are using non-Intel graphics. (Though many of those with non-Intel graphics will have PWM.)

Of course, there are good reasons why the Librems use Intel graphics, so it comes down to what’s more important.

A somewhat more realistic prospect might be to use a high PWM frequency. Some people say that a higher frequency stops them having problems with PWM.

Intel graphics do allow for high frequencies to be set, but really the manufacturer should be the one who chooses the frequency, because it needs to be suitable for the actual hardware to ensure stability and avoid damaging it over time.

And then there’s the workaround of just always using it at 100% brightness, which, by rights, should result in no PWM. I tend to do that with my (non-Librem) laptop, since I’m usually in a well-lit location without concerns about battery life.

3

If anyone with a Librem wants to test it for PWM, one simple test is to take a steel rule and wave it back and forth in front of the screen, preferably at a low brightness setting.

If there is no PWM, or high-frequency PWM, you should see a smooth blur of the ruler, but if there is low-frequency PWM, the blur should break up into discrete steps.

(Or you can use your hand instead of a ruler, or measure it with an oscilloscope.)

2 Likes
4

Yes, after a certain frequency the eye just physically stops seeing the flicker from PWM, so that would definitely be a solution.

Here is another very good guide on what PWM screens are, and why they are problematic to a lot of people: http://www.tftcentral.co.uk/articles/pulse_width_modulation.htm

5

I’ll just leave this here for you: https://justgetflux.com

It’s a little tool I’ve known about for ages. Might be useful to ya.

I don’t use it much, but some people I’ve noted it to have downloaded it and told me they love it and that it even helps them to sleep at night, so there’s that.

1 Like
6

Thanks @Alex, I’m aware of this SW (using redshift personally). It is not a solution for the HW problem mentioned here, unfortunately.

7

So, is there somebody with a librem notebook (13" preferably) who can measure that for us?

8

Wow! Thank you very much, @nicole.faerber , this is a very unexpected (and GREAT!) possible solution.
( Replying to your post in the other thread. )
Can someone test here?
https://wiki.archlinux.org/index.php/Backlight#Backlight_PWM_modulation_frequency_.28Intel_i915_only.29
I’ll test on my ntb, but dont have librem yet.

A few questions arise:

  • will the HW allow the changes?
  • then why wouldn’t the manufacturer set the better (higher) freq already?
  • what are the implications of rising the PWM frequency? higher power draw of the display?
9

Using a Librem 15v3, with the lowest brightness setting that still lights the backlight, I see no flicker when moving my hand or a ruler over the screen in a dark room.

1 Like
10

I have used the intel_reg write command seen in that Arch Linux wiki page to alter the backlight frequency on my laptop (this is what I was referring to when I said you can set higher frequencies :wink: ).

The relevant register is a documented feature in the Intel Programmer’s Reference Manuals for the hardware, so it should allow you to set different values. (The precise register address might vary between hardware generations, so it’s probably worth searching the PRM PDFs for instances of “backlight” if you have different hardware. 0x8254 is correct for 2015-2016 Skylake at least.)

The value you set persists until the GPU is next reset, so it goes back to the default if you suspend or shut down the system. It’s not permanent, hence the workarounds using udev to make it faux-permanent.

While the register value for the frequency can be set to anything between 3Hz and 187500Hz on my Clevo, there are hardware design considerations to take into account, about which I can only speculate and make semi-educated guesses:

  • To achieve PWM, the backlight drive current will, at some point or another, be being switched on and off by one or more transistors. Transistors perform differently at different frequencies and different ones are optimised for different operating frequencies. There’s a good chance that boosting the frequency will cause a transistor to get warmer than usual.
  • There might be inductors or capacitors in the circuit which were validated for a particular frequency. They could make the circuit unstable at dramatically different frequencies.
  • There might even be a microcontroller or two between the GPU and the transistor. That will have its own frequency limitations.
  • Intel probably didn’t design their GPU for the specific components that are in any one laptop, so they couldn’t limit the frequency to only allow values that are sensible for the actual hardware.

I’d say it’s reasonably safe to cautiously experiment (gradually changing the frequency in small steps), but if anything weird happens you might want to back off.

Experimentally, on my non-Librem hardware, I found that:

  • The default was approximately 200Hz.
  • My backlight would not work at all below about 50Hz. (Black, unilluminated screen.)
  • I was able to set it to 18750Hz, but after about fifteen minutes running at that frequency it started flickering in a glitchy, slightly erratic manner, as though it was going to fail.
  • I had the same problem at 9375Hz, except it lasted a bit longer before it started flickering.
  • 4687.5Hz created an audible noise (like coil whine) and lasted even longer, but still eventually flickered.
  • 2347.75Hz seemed fairly reliable (and didn’t make an audible noise).
  • High frequencies only caused problems at less than 100% brightness. (Which makes sense, because 100% is just constant “on” at any frequency.)

I don’t have the nerve to try setting it to 187500Hz!

Of course, these are results for a different laptop, not a Librem. A Librem may perform similarly, or differently.

If I’d persisted with an altered frequency, I would have needed a workaround to enable me to adjust the brightness, since the standard brightness controls assumed the original PWM frequency. Adjusting the brightness using the keyboard or power management system caused a duty cycle to be set in the register that didn’t take account of the modified frequency.

The duty cycle value in the register needs to be between 0 and the PWM period that’s been set in the other 4 bits of the register. So, if you increase the PWM frequency by a factor of 10, but the brightness control continues setting the same duty cycles it always has, then anything above 10% brightness actually gives you 100% brightness (with 5% giving 50%, and so on). I never got as far as figuring out how to fix that, though it’s trivial to adjust the brightness by setting the appropriate duty cycle in the register.

1 Like