Linux's Display Brightness/Backlight Interface Is Finally Being Overhauled

[akarypid]

The whole thread is about removal and addition of monitors.
The article is about brightness regulation.
I'm not sure what your on about?

Back on topic: why is it not possible to do this on regular desktop monitors?

[oiaohm]

Back on topic: why is it not possible to do this on regular desktop monitors?

The horrible part here it is possible to control some desktop monitors brightness over HDMI and Displayport but mixture of not standard or not required by standard. HDMI-CEC does not have a clear standard for doing brightness but brightness of monitor can be done this way. Also the Displayport auxiliary channel can do HDMI-CEC and Displayport particular brightness controls.

Yes the displayport standard has standards for doing brightness control problem here is monitors supporting displayport are not required to have those features.

Yes CEC standard itself does not define how to do brightness but the vendor of monitor is allowed to put out what ever controls they like on CEC. Lets just say HDMI-CEC is IR remote encoding all over again where multi different vendors can use the same signal for different functions. Maybe someone will do BPF program support for HDMI CEC as we have for IR devices to hook up display controls.

I would love to see the day when software could bring up the monitor On-screen display by CEC when using monitor color calibration tools and calibrate the monitor.

So the answer is it truly possible control everything you can alter by the OSD of a monitor/TV from a computer as long as the monitor/TV decides to expose this information over CEC with hdmi or over display port auxiliary channel but there limited standards on how todo this. Worst part is there is no standard to expose this information the same way between vendors or even between models from the same vendor.

Yes some of the problem is people buying monitors are not asking for hdmi CEC support to control the OSD.

[syrjala]

By far the most common way to control brightness of external monitors is DDC/CI. And a lot of monitors (at least ones meant for computer use) do support it. But I've found it to be somewhat buggy on various monitors. Eg. I have some monitors that can't do DDC/CI succesfully even at the standard 100kHz i²c bus speed, which is a real problem when connected through a DP->whatever dongle that doesn't support reducing the i²c bus speed.

[Anux]

Re-attach a screen and one of those rows of panes goes back to it....

And which one should that be? A random one? What if I wanted the other one on my new monitor? Now I have to move even more windows or at least 2 virt desktops.

Back on topic: why is it not possible to do this on regular desktop monitors?

I would love to have that for my monitor but like oiaohm excellently explained there is no good standard. I guess the article is only talking about laptop screens.

[oiaohm]

By far the most common way to control brightness of external monitors is DDC/CI. And a lot of monitors (at least ones meant for computer use) do support it. But I've found it to be somewhat buggy on various monitors. Eg. I have some monitors that can't do DDC/CI succesfully even at the standard 100kHz i²c bus speed, which is a real problem when connected through a DP->whatever dongle that doesn't support reducing the i²c bus speed.

That a new one to me none of my monitors in fact support DDC/CI.

https://www.ddcutil.com/monitor_notes/

Yes DDC/CI is still a huge non standard mess.

[oiaohm]

I would love to have that for my monitor but like oiaohm excellently explained there is no good standard. I guess the article is only talking about laptop screens.

Sorting out the interface for laptop screens could be in future used for desktop screens. I did not know about the DDC/CI standard. So we have now 3 different ways do doing the same horrible. Display port standard, HDMI CEC standard and DDC/CI standard. All of them are implemented in a do you fell lucky punk way.

Please Vesa or some other monitor certification body make this part of some monitor standard one of them. So that vendors have to include something useful.

[akarypid]

And which one should that be? A random one? What if I wanted the other one on my new monitor? Now I have to move even more windows or at least 2 virt desktops.

Not a random one. Let the user choose!

If the monitor you connected supports the resolution of a saved set of panes, give the user the option to move them onto the newly attached monitor. Actually, include even the non-matching panes, with a warning that windows may get rearranged!

Automation is the enemy of usability. This manual way would address 90% of the use case, which is: we use the same monitors all the time! One is the laptop screen and the other one (or two) lies on our desk. We'd just pick the same panes to go back to the same monitors. If we ever connected to a different monitor, we can choose to do it or not.

Basically you have virtual monitors and each one has virtual desktops. When you connect a monitor you can choose a virtual monitor to render on it, or create a new one. You can destroy a virtual monitor and choose another to move the windows onto (which may get rearranged if they don't have matching resolutions).

Everyone is focusing on the 10% use case and trying to automate and stuff, and and the net result is that everyone just gets an experience that doesn't quite work...

If this was in place, people would next ask for a very simple thing: whenever I attach a monitor, remember the mode/geometry in my list of saved monitors. Then I can select specific virtual monitors to be auto-mapped to specific physical monitors (which would be a list similar to saved WiFi networks).

I really don't understand how they will ever get his to work properly auto-magically. They should just offer this simple mental model of virtual/physical monitors which is easy to understand and most users will "get the idea" easily...

[Anux]

If the monitor you connected supports the resolution of a saved set of panes, give the user the option to move them onto the newly attached monitor. Actually, include even the non-matching panes, with a warning that windows may get rearranged!

That would be a nice solution, but to combine this with extended monitors (two monitors acting as one) would be really hard with many edge cases.

[digitaltrails]

That a new one to me none of my monitors in fact support DDC/CI.

https://www.ddcutil.com/monitor_notes/

Yes DDC/CI is still a huge non standard mess.

Ddcutil may work with many external monitors not in the supported list.

I've tried several branded monitors made in the last decade or so (such as HP, Beng, LG, Dell) and they at least support DDC/CI for brightness and contrast. In other cases, some tweaking may help. I've written my own system tray front end to ddcutil (https://github.com/digitaltrails/vdu_controls) which attempts to work around DDC/CI implementations that are incomplete to at least provide brightness and contrast.

So far I've only encountered one external monitor that lacks DDC/CI entirely: a cheap IPS LCD purchased from Aliexpress. It's pretty barebones, I can see the backlight shining through the vesa mount holes.

[digitaltrails]

Back on topic: why is it not possible to do this on regular desktop monitors?

See https://www.ddcutil.com/, https://github.com/digitaltrails/vdu_controls (I wrote vdu_controls - a mini system-tray accessory front end to ddcutil, works on KDE, gnome, deepin and others).

Ddcutil seems robust. I've managed to use it with a variety of monitors and have helped several others get ddcuti/vdu_controls going with monitors with more cranky DDC/CI implementations. The author of ddcutil has also written a comprehensive DDCUI GUI.

Plus there are other implementations of DDC/CI such as https://github.com/ddccontrol/ddccontrol and other GUI's such as https://github.com/newAM/monitorcontrol. Neither of which I have tried. I think there may be more DDC/CI utilities out there.