| Summary: | Allow software brightness on top of hardware brightness | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Riccardo Robecchi <sephiroth_pk> |
| Component: | platform-drm | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.5.3 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Riccardo Robecchi
2025-11-26 19:12:27 UTC
No such application for gamma luts will ever be supported. It doesn't make any sense in a color managed world and has proven again and again and again to be the completely wrong approach on X11. Your actual request, software brightness, is something we had planned already. I didn't find an existing bug report about it though, so let's make this one about that. Why is it the wrong approach? Literally all other platforms support it. It's the wrong approach because apps use it for all sorts of bad ideas, from - doing night light without the required color management steps, making colors worse and inaccurate - applying custom "gamma" curves, again without taking color management into account - implementing brightness sliders in games (CS:GO did that, as a popular example, because SDL had (has?) an API for that) - applying custom "driver" options, like NVidia did Each and every one of these overwrites each other. In the X11 session, color management is completely unreliable because of that. You open the wrong settings page (KGamma), and just like that, your color calibration is gone. You open the Nvidia driver app, some game, same thing. Even output hotplugs mess it up on X11, because KWin and colord-kde race for adjusting night light and color calibration respectively... Iow, because of this API "decision" on Xorg, color management and night light both are completely unreliable there. That's to say nothing of HDR, which such an API just doesn't work for at all. Thanks for the explanation. I understand your concern, however I feel like the vast majority of people do not care about colour management and colour calibration. The option to manage colour should be there, but I feel it shouldn't trump over other needs. To give you an example of a legitimate use for such an API: an application that automates changing the gamma in order to do the calibration (which brings us to the known Wayland issue "No way to change the gamma or manually adjust the colors without generating or finding an appropriate ICC profile"). I wonder if there is a way to allow for third-party apps to do night light and other things without breaking colour calibration entirely. Would it be possible to disable colour calibration when the apps are active, or impede the use of the apps if a colour profile is being used? I think the latter is what happens on Windows, as an example (but I might be wrong there). Display profiling is in no way related to setting arbitrary LUTs on a display, and neither is configuring colors without an ICC profile. The fact that these problems have been "solved" in the most hacky and terrible way on Xorg is not an argument for copying that approach at all. This decision will not be changed, no amount of arguing will change that. |