Why do monitor manufacturers limit the minimum brightness? And can firmware binaries be patched by the user?

[RationalFragile]

Hi, my post is two questions:

I watch a lot of reviews from techless on Youtube because he includes the minimum brightness. And I noticed most monitors have "too high minimum brightness" above 100nits.
Whether the monitor uses PWM or amplitude or both to control the backlight, I understand why the maximum brightness cannot be exceeded (100% PWM or max amplitude that will not fry the LED). But why would the minimum brightness not go down until the blacklight is turned off?

Is there a technical reason why manufacturers don't allow lower minimum brightness? Or is it just "assumed" good enough and hardcoded in the firmware?

------------------------------------------

I had this issue with my HP 15 notebook laptop, it was too bright at night and I spent like years trying to find a way to control the backlight. And eventually I did it. (There is an address in memory of the intel HD graphics driver that when set will change the PWM of the backlight to any value below the max.) So now I enjoy the ability to set the brightness as low as I want (even turn off the backlight if I want and keep the color pixels on). But for desktop monitors, the controller controlling the backlight is inside the monitor, so I can't possibly access it just from the computer, it needs to be done from the firmware running on that controller.

So can this be done with desktop monitors? Can I find the firmware binaries, analyze them with reverse engineering tools and find the backlight control range and remove the lower bound limit? AND will the monitor even allow me to install a patched firmware or does it use some sort of checksum/signature enforcement?

[Chief Blur Buster]

There are multiple reasons, some decision-by-commitee, and some technological limitations.

- A lot of hardcoded brightness ranges
- A lot of parts don't operate reliably at ultrashort pulses (e.g. random candlelight flicker effects)
- A lot of people get headaches at ultrashort pulses
- There are utilities that dim the screen via software, to get more brightness headroom below without the eyestrain of PWM. NVIDIA Control Panel lets you do this.

Generally, you could theoretically hack the firmware of a monitor. Some use enforcement while many do not. I've seen some people pull firmwares (via mstar-style dongles), like backing up the firmware on their existing monitor, modifying it, and reinstalling it.

I've seen some people create system tray utilities that automatically sends DDC commands to set brightnesses even lower, once they discovered the undocumented DDC register via Windows SetVCPFeature() API, which can operate multiple common settings of your monitor's OSD settings directly from a Windows program.

For over two decades VESA standardized a MCCS ( https://www.google.com/search?q=VESA+MCCS+DDC+2.2 ) -- the DDC/CI brightness address is 0x10, and you can control your monitor's brightness from the computer that way, but if value 0x01 written to DDC address 0x10 is still not dim enough, then there might be an additional DDC command that controls the PWM to access even lower brightnesses, but you'd have to download a utility (such as Windows softmccs or Linux ddcutil) to try to reverse engineer the DDC register before you created a system tray utility. Much easier than hacking firmware.

Now, sometimes laptop screens don't implement MCCS, so you have to use an external monitor or find other hacky ways.

[RationalFragile]

Thank you so much for the help!

Ah you mean that the firmware might be imposing a different range for the OSD than for the brightness/luminance/backlight set through DDC/CI commands. That's very interesting and definitely worth trying before attempting anything with the firmware itself.

Unfortunately though, I think it depends on the firmware, so every firmware might be different and the specs specify that the values are just a mapping, so who wrote the firmware decides on that mapping. I don't have a desktop monitor to test with (I'm researching this to decide if I should buy one). But here is an example of someone who tried DDC/CI brightness, and still got the exact same range as the OSD: https://github.com/rockowitz/ddcutil/is ... -633436823 though I think they didn't try with all the available commands (the now deprecated 0x13 for the backlight) but they might have still gotten the same range if that's what the firmware wants to impose.

Finally, I'm still skeptical that it's a hardware limitation (because it can be achieved) and I don't think low duty cycles cause flickering/headaches because the frequency stays the same. Even with my laptop's mere 800Hz PWM, I see no flickering at almost black backlight. The common controllers I found a datasheet for drive the PWM at 6KHz or more, and has 8bits or more accuracy over the duty cycle, so at least 1/256 maximum brightness. I think the plausible cause is this sentence in the specs: "Care should be taken to avoid the situation where the white backlight level ratio approaches 0 … this may be non-recoverable since user will not be able to see the image." I think anything other than zero is possible to see (you can even see zero if you shine a flashlight on it) and even if you soft-lock yourself, at worst you'll need a second monitor to reset the other one. And they could make it reset on power-on or if you hold the power button for 3 seconds or something if soft-bricking is the concern.

Again, thank you so much for sharing all the valuable information!