Sebastian Wick

Over the last year, I overhauled the screen brightness handling in GNOME! This will become available in the upcoming 49 release, but you can already try it on GNOME OS.

https://blog.sebastianwick.net/posts/gnome-49-backlight-changes/

GNOME 49 Backlight Changes

One of the things I’m working on at Red Hat is HDR support. HDR is inherently linked to luminance (brightness, but ignoring human perception) which makes it an important parameter for us that we would like to be in control of. One reason is rather stupid. Most external HDR displays refuse to let the user control the luminance in their on-screen-display (OSD) if the display is in HDR mode. Why? Good question. Read my previous blog post.

swick's blog
Aug 8, 2025 at 4:36pmWeb
Show threadrazzeAug 8, 2025
@swick my alarm bell is ringing now, tried gnome os a few weeks ago on my new framework 13 and auto brightness was broken, so I had to turn it off. Switched to fedora now, that's fine.
Show threadSebastian WickAug 8, 2025
@razze Very likely that this is a regression I introduced because I have no hardware with ALS. If you're comfortable building g-s and g-s-d, ping me on matrix and we can debug this.
Show threadrazzeAug 9, 2025
@swick if I can find a cheap nvme for a test install, we can probably figure that out. But might need a week or two.
Show threadngz0Aug 9, 2025
@swick in 49 on my laptop brightness can't be changed when in HDR. Is it expected for now?
Show threadSebastian WickAug 15, 2025
@ngz0 The problem with integrated panels is that they often offer sysfs backlights which then simply stop having any effect in HDR mode. If they were exposed via KMS instead we could notice that they are not usable after a mode set into HDR. A patch just got merged which always uses the "software" backlight for now. Unfortunately a side-effect of that is that if you had working driver/hardware level backlight control in HDR mode, you're now stuck with the "software" backlight.
Show threadeobetAug 9, 2025
@swick ooh, I hope a side effect of these updates might be that the lowest brigthness setting on my laptop isn’t pitch black and the next key press up is the light of a thousand suns! 😅
Show threadSebastian WickAug 15, 2025
@eobet Unfortunately, no. We still have no information about the mapping of the values to luminance. It's something we really *want* to have, and there are vague plans to get there.
Show threadspykeAug 9, 2025
@swick Could you please explain a little bit more? Is this "HDR brightness" just a multiplier that is applied to the final value? So, if the content pixel had 200nit brightness and I set the brightness to 0.5, then the screen would light up at 100nit? And also are there any plans to introduce HGiG and maybe even built in tone mapping controlled into the composer? For example to cut off at 1000nit vs. tone map the range 800..4000 into 800..1000nit.
Show threadspykeAug 9, 2025
@swick Are there any differences in the results of this slider for OLED vs. LCD?
Show threadSebastian WickAug 15, 2025
@spyke The brightness slider is a multiplier for the reference white level of the output. Content gets anchored to that level. We now have tone-mapping support but that's not helpful in HDR mode currently because we use the entire BT.2100 color volume even if the monitor only supports a subset of that. There is no way to detect OLED vs back-lit technologies currently. EDID has support for that in theory but in practice the data is not available.
Show threadspykeAug 15, 2025
@swick Any chance of making an HDR calibration menu similar to PlayStation 5? By tone-mapping I meat what would happen with a color 1500nit bright if the display can do only 1000nit. Depending of the display it may cut off (Sony) or do a roll off by some curve (Samsung, 1500 becomes 850). I'm just trying to wrap my mind around how GNOME HDR is different from a console or an Apple TV. Right now it seems there are similar issues as we had with first HDR TVs in 2016.
Show threadSebastian WickAug 15, 2025
@spyke We currently just depend on the display to tone map, but that's unpredictable. One approach is to tone map in the compositor to the color volume the display actually supports to avoid that but that's often not great either. What we really want is some kind of SBTM mode where we get predictable behavior from the display and do tone mapping entirely in the compositor.
Show threadspykeAug 15, 2025
@swick Why not the easy way game consoles go with a wizard to find max levels for 10%, 100%, the black level, and use it for tone mapping in the compositor?
Show threadSebastian WickAug 15, 2025
@spyke As we currently don't even try to get the color volume from anywhere this would be pointless to add. But sure, we could provide a tool like that to override what we get from monitors and a quirks db. It should just work though, and the only reason why it doesn't is the artificially bad behavior and metadata in BT.2100 HDR modes.