☃️karolherbst☃️The biggest killer feature of HDR is to have finally working brightness controls for displays 🙃
Jon Koops 🇪🇺@karolherbst Actually curious how this works. KDE has a built-in brightness slider, allegedly it should talk to the display to control the brightness (at least without HDR enabled). But I kind of feel like it just overlays filter to dim the pixels.
@jonkoops Well, laptop displays generally do have interfaces (ACPI/WMI/GPU/custom, it's a disaster) for the brightness, just external displays didn't really. But you should be able to tell if the image just gets darker or if there is less light.
I think OLED displays also have a standard interface for brightness? Not quite sure.
elly@karolherbst Uuh, Karol, you can control brightness on external displays using DDI (which in itself is just... I2C). That being said, I've been using a laptop with AMOLED screen for 4 years and I'm hyped as heck that external monitors are becoming affordable. I would love a 16:10 or 3:2 ~28in OLED but that's a different story...
@elly yeah.. but I have rarely seen it used by external DisplayPort displays outside of OLED, but maybe I just got very unlucky?
Or maybe it's just an implementation limitation on Linux? That being said.. my HDR display is the first one I can control the brightness of from my Linux system.
@karolherbst seems like it? Almost all displays I have support it, with the exception of NEC 2470WNX from... 2007 (and even that probably would work if it was connected over a native DVI interface)
@elly interesting.. and that just works properly out of the box on linux desktop systems?
@elly okay interesting, that one indeed seems to work on the display I've used previously.
So now I'm wondering why it's not really set up for Linux desktops to use, or why there isn't a sysfs backlight device entry for this?
Or is the problem that you need a database of supported displays and it's all custom per device?
@karolherbst I think you can query commands, none of my displays (except for ancient Dells from 2007) are in the database but work just fine. I guess it could be done as a userspace daemon (similar to libinput)?
@elly yeah, doing that in Userspace does sound like a good approach here if we'd need to rely on databases. If it's a standardized interface doing it in the kernel might be good enough + adding quirks for hardware where it doesn't.
But I'm now more surprised that this hasn't happened yet and I'm wondering why.
kcxt
Sebastian Wick@karolherbst @elly the KDE thing uses the user space ddd/ci libraries which requires i2c-dev and screwing up permissions on the device. some apple displays have a usb thingy for it instead of the i2c ddc/ci.
we could wire all of that up but because it requires a kernel module which is clearly not meant to be used in production and has issues with permissions, that never seemed like a good idea.
there were efforts to create a sysfs backlight from ddc/ci in the kernel but hans degoede didn't want to expose them because it could screw up the existing logic to bind a sysfs backlight to a display.
there is an out of tree kernel module which does this, but it can't properly autodetect ddc/ci, so you still have to much around and write magic values into sysfs to make it work. once you do that, you get a sysfs backlight and mutter will pick it up and bind it to the right monitor.
the realistic path forward is exposing backlights in KMS. it's new API, can't screw up existing sysfs user space, and fixes the issue with binding the backlight to a specific display (and a whole lot of other things). buuut, hans is now only doing camera stuff and mario limonciello wanted to work on this but probably has more important things to do.
@karolherbst @elly ah, yeah, and ddc/ci is notoriously bad. for reasons we always set the backlight to 100% before entering HDR mode, so one of my external displays just completely breaks because the HDR backlight control and the still-SDR-ddci/ci-command somehow conflict.
@swick @elly right and if it's that bad we really want to have a database of displays where it works reliably.
But that's also going to be painful to coordinate with the kernel side of things and see if they already expose a backlight device and to figure out which display it belongs to etc...
mhh yeah, I guess I understand now why nobody did it yet.