In the feedback about dropping X11 support, one very surprisingly common comment is from users saying they "need" kgamma, a simple tool that allows the user to adjust the gamma, red, blue and green that gets drawn to the screen operating directly on the X server.
Visually-impaired/low-vision user here. I’m one of the people who “need” gamma. Without it, as I’ve said before, using Plasma is harder. Gamma does not equate to brightness, it directly affects real contrast in a way that makes visual information easier to differentiate and process.
Incredibly grateful for @David_Edmundson’s work on this, - it’s a huge help. I’m currently using custom 0.90G icc files, and the functionality exposed via the current Display Configuration UI has allowed me to keep setting gamma in a way that allows for custom contrast. I’ll keep using it because it works well. While I’d never tweak RGB levels independently of themselves, it’s absolutely a great tool to have.
I’d be interested to see if the sliders can be locked together. As for having it as a separate tool and not including it in native Plasma, that’s a separate discussion. Can I work by uploading a custom icc file? Yes. Would it easier (subjectively) to have access to a native UI to do this within the desktop environment rather than uploading an icc file, checking the effect, and then tweaking and reloading several dozen times? Absolutely.
I’m not sure if visual impairment/low-vision is the only edge-case that this feature caters to, I’m so grateful for the effort having been made, but I’d still like to point out the “need” really doesn’t need to be in quotes, it’s a genuine feature and function of HCI UX that supports variable and low vision.
>I’m not sure if visual impairment/low-vision is the only edge-case that this feature caters to, I’m so grateful for the effort having been made, but I’d still like to point out the “need” really doesn’t need to be in quotes, it’s a genuine feature and function of HCI UX that supports variable and low vision.
Thanks for the feedback. Anything for accessibility I’m much happier to support officially.
Can you talk me through this use-case and the gamma for accessibility in general?
I’m asking because we also have a way to set shaders on a per-window basis. We have an opportunity to not just copy what exists but to take a step back and make sure we’re solving your use-case in the best way possible.
If it’s for text reading but not videos there’s scope for us to do something that’s going to be better.
Absolutely, happy to outline the usecase. Really appreciate your taking the time.
I just need to state (perhaps obviously) that blindness, low vision and visual impairment are a spectrum. Blindness does not mean no vision at all. On any given day, my vision can be variable. Some days it’s better than others. Historically, I’ve used a mix of X11’s xrandr and custom themes from KDE 5.x onwards to build specific grades of contrast based on vision for any given day. It worked well.
When it comes to wanting sliders to be locked, here’s my clunky explanation of why, by way of my old x11 alias : - essentially locking those sliders by way of defining values identically because we’re not changing hues per se.
alias dim=‘xrandr --output DisplayPort-0 --gamma 0.850:0.850:0.850’
(I’m literally doing the same thing now in Wayland using a custom icc file, albeit loading variable gamma levels by file, clunky but workable, and hugely appreciate that option, it’s a gamechanger!)
The primary reasons for needing concise gamma control for me is specific to reading text; improving contrast for text and overall display clarity. Linux has had excellent font rendering for a while now, gamma control is the (final) missing piece that controls how dark or light shades look between “pure black” and “pure white” - I’ve put those in quotes because there’s technically no such thing when referencing monitors; every output will have a hue of one form or another. I think it’s a gamma level of 2.2 for the sRGB standard, if that gamma value is too low, your display looks washed out, too high and everything is just black. The colour temp really dictates whether whites look warm, neutral, or reddish. Sadly monitors don’t always come correctly calibrated in firmware, and not everyone has a colorimeter. (my old Asus VG248 was, for example, perfectly calibrated out of the box at 60Hz, and a washed out mess at 120Hz).
Thinking about it more widely, most people will adjust the white-point (colour temperature) of their monitor to professional requirements or personal taste - and different colour temperatures can need different levels of gamma (this is particularly important for anyone doing any kind of work with digital media, - not something I do, but another use case to point out).
Brightness ≠ Gamma. It never will. Brightness scales output intensity, while gamma reshapes mid-tones, reduces eyestrain without crushing blacks, it’s what’s actually needed more for visually impaired users in high-contrast environments. Wayland’s security model treats gamma as “display state”, not “user preference”, sensible in theory, but mildly hostile in practice. I think regardless of how it’s implemented, surfacing an accessible tool to compensate for both hardware as well as whatever visual acuity the user has, or doesn’t have, is the kindest thing KDE eV can do. We don’t often think of software as being kind, but there’s an opportunity here to highlight the ways in which KDE genuinely makes peoples’ lives better. Thanks again!