https://bugs.kde.org/show_bug.cgi?id=499934
--- Comment #24 from Adam Tibbetts <m...@adamtibbetts.com> --- I think, trying to parse this, is that separate brightness ranges depending on content type would be a feature request. Since the current functionality is, in a narrow sense, how HDR 'should' work. As end-users this implementation is incomplete/broken, not in the technical sense, but in a usability sense. So, potential Feature Request: Improve system usability on HDR displays by allowing HDR content to have its own distinct brightness setting separate from SDR content. LewisT's comment is a good example of a use case for that feature. I realize in the back-end there's not necessarily a hard distinction. But in the font-end there absolutely is, and this implementation doesn't work the way I (and many others) want it to. This is one of those 'end-users are wrong' cases where the end-users are actually right, because we're not trying to get the most programatically correct outcome, we're trying to get the most 'usable' outcome. And this current setup is not as usable. If in future this leads to more work, as the desktop itself maybe becomes less distinct as 'SDR', then I think that work is highly worthwhile. My computer is most *usable* when these concepts are different. If that's an abstraction from what's really happening, then please abstract it away. I want content with 'brightness data' to be treated one way, and content with the old way of only color data to be treated another. Apologies if I'm right and I could have just made a feature request, but I don't know how. Are feature requests bugs in KDE land? Or ideally someone with a better idea of how this works could do it, but if no one does I'll have a go, it's pretty much essential to the usability of my desktop. -- You are receiving this mail because: You are watching all bug changes.
