Yet, there is already professional software solution called IRIS for all Librem users out here not already pleased with their screen. Why not to invite Mr. Daniel Georgiev on board and see what he can do for Librem 5 during development phase?
The current plan is to use this to drive the backlight, which means no PWM, and therefore no flicker.
I read a study from a lighting industry publication that claimed anything above 10Khz is safe, but this hasn’t really been studied to the extent it’s needed.
Apple for most MacBooks since 2010 (and probably iPhones) have used 100Khz PWM below 50% brightness. So good even cheap oscilloscopes were “fooled” into thinking it was PWM free.
A bit ambitious, but maybe for the Librem 5 2.0 or whatever next year
No PWM would be better, but I have damaged eyes and they were fine with the LG V20 which has similar ~2.4Khz PWM below a certain brightness (37%)
A while ago I tested some different backlight frequencies on my laptop. I found that:
- 200Hz flicker was fairly obvious and noticeable
- 1000Hz was less apparent in normal use, but obvious when specifically looking for flicker
- 2000Hz was on the verge of being impossible to discern.
- 4000Hz was more or less imperceptible.
I don’t really like the idea of PWM for backlights. Just because it’s not perceptible doesn’t mean it’s not searing my retinas with super bright light 200 times a second! But I’m not someone who finds it much of a problem in practice. Still, I’m glad the phone won’t have it.
Well, it looks like you’ve got the purpose of my intention. But first and to be correct, with LG V20 measurable flicker was not detected at brightness levels of 90% and 100%. And it was 5.7 inches IPS with only 16M colors, with same (mentioned) resolution: 1440×2560 pixels. Therefore here (relativly outside of the PWM topic), let me clear up why I left 720p number(s): Vivante GC7000Lite GPU should support 720p60 directly over the MIPI DSI to the capacitive touch screen meaning (simplifying here) 720×2=1440 … resulting in much better 720p picture (and its color) reproduction (in short). To my understanding 1080p and higher resolutions will be projected over USB-C (without usage of Mini-HDMI). Is it 1440 pixels 5.7 IPS screen nowadays more expensive than 720 pixels 5.7 IPS screen? Resolution close to 720×1440 Rocktech JH057N00900 is 1440×2960 with almost identical 18.5:9 aspect ratio (instead of 2:1).
That would be really cool! Thanks a lot!
In case anyone is interested, you can already do the same thing with xrandr --brightness (if I understand what IRIS is doing correctly). I don’t know if wayland has an equivalent. I very much dislike that method of dimming though. For my eyes, I actually find it uncomfortable. I am better off using it on full brightness during the day in well lit conditions. Also, the contrast of the display is reduced using that method.
Well, I bought Iris mini Pro (try icon only) for my Lenovo X240 with IPS screen (after using it for relatively long time as new) as its flicker was terrible within 20-40%. I am not sure any more but I believe I was trying xrandr options under Debian without any benefit. Basically you have right … as after installation of IRIS I increased manufacturer brightness to 100% … and the rest I (can) control with Iris mini Pro. For the moment my IRIS brightness is 55% (Custom) with usage of 2700K light color and there is no flicker (pleased with this result/purpose). Usually for adjustments I use Hidden features and like them.
Here is YouTube link on How to remove PWM Flicker with Iris. And, if so, just for your awareness, (by registration) IRIS “knows” about your location (control of its authorized usage).
And sorry, there is no Wayland option yet and (maybe) it may take some more time.
Why not just convert to voltage?
Because LEDs have a threshold voltage. That’s the whole point. You can always dim between, e.g. 1.1V and 1.6V. But at 1.0V it might turn off. And that’s why many screens cannot be dimmed as low as you would like them to.
To dim below that threshold, PWM is the solution, not the problem, even though one might not like that solution. Another one would be an OLED display.
To further elaborate on this, light emission from an LED is a quantum process which happens at one very specific frequency (all LEDs are monochromatic, “white” LEDs are blue and have several fluorescent phosphors to absorb and re-emit light in other parts of the spectrum to make them appear white). This is a well-defined transition between two energy states, and will not happen unless an electron going through that circuit has at least that much energy - the potential difference (voltage) multiplied by the charge on the electron (a constant). This transition takes exactly this much energy from the electron and no more. Below this voltage, absolutely nothing will happen.
Any dimming from lowering the voltage is actually caused by a reduction in current (I = V/R). Current is what defines the brightness - one electron releases one photon in an LED, and current is the number of electrons per unit time.
To vary the brightness of an LED, you therefore need to hold the voltage constant and vary the current. Not an easy task to accomplish (it requires reactive circuit elements) and so the most common method is to just flicker it on and off several (thousand?) times per second and let your eyes average it out. In the case of the TI chip listed, the datasheet listed several internal frequencies which it uses for some purpose. The lowest was 100 KHz.
So even if it’s direct PWM, that’s far above what any human eye could see. It’s also possible that there are some active circuit elements after the output stage which will act to smooth out the current flow (I’m guessing that a capacitor at the minimum is necessary to hold the voltage above the threshold, then an inductor to smooth out the current variations, but it’s been a long time since I did anything circuit-related).
Thanks, xrandr helps as software solution when light conditions change as well! I have stayed with device screen brightness at 100% and have tried:
xrandr --current
xrandr --output eDP-1 --brightness 0.45
or on evening time something like this:
xrandr --output eDP-1 --gamma 1.1:0.8:0.7 --brightness 0.35
Default --gamma for red:green:blue is 1:1:1 but requires a little bit of understanding for changing it and getting needed/liked color temperature.
Hi @Quarnero, good job! I would recommend trying redshift to change the colour temperature rather than using xrandr’s gamma function. Or if you are a Gnome user, I believe the newer versions have a colour temperature thing built in to the UI now.
Reasons I hate LED lighting…
And it would be a whole lot better than 200Hz, which is great!
Please translate if/as needed … it is about courage (and knowledge of course):
“This may be the first consumer report on the impact of mobile screen technology on human eye health (worthy to read in depth)”
“I am talking about this today: the AMOLED screen has long been an established fact, but I dare not say it before”
“I have officially sent a letter of inquiry to Samsung Electronics - questioning the harm of Samsung AMOLED screen to the human eye”
Even though looking forward, I wish (or dream) there is an option for a custom 18:9 (2:1) display (by paying extra cost) like this one:
CGS technology and its low(er) power consumption, surrounding circuits and functional elements built into the LCD panel, etc. is described here.
And, as Purism is already setting very respectable standard I may be pleased with whatever display available within the production deadline to make L5(+) Vivante GC7000Lite GPU allive (and happy).
Reading in a backlight display is not as good as reading a paper, since the reader is not looking to direct light but a reflected light.
E-ink displays provide a experience like reading a paper at sunlight. Also smartphones with e-ink displays have a lower battery comsumption, representing a larger autonomy.
It would be great Purism think in add e-ink display to it´s devices.
I’ll try reading it later with machine translation, but could someone translate these documents?
I am sorry that i cannot help for real. Machine translation (although not precise and sometimes confusing) may provide just enough of touch to what 田小宇 wanted to share with (all of) us (I believe so). I hope you’ll find someone to help you with this one (because it matters).
No promises but I’ll ask around.
However I found this (from possibly the same author of those documents?)