Something that’s been bugging me for a while is the lack of 24-bit visuals when running X in 30-bit colour depth. This causes Steam for Linux to break[1].
So my question is (mainly to the NVIDIA developers), why aren’t there any 24-bit visuals when running in 30-bit mode? I can kinda understand in the old days, when everything rendered to the same back buffer everything had to use a compatible visual. But surely in a composited desktop, that’s no longer an issue. Is this something that Wayland/Weston solves better? I haven’t taken the plunge to upgrade my F24 install just yet.
This hasn’t really been an issue so far, since I only have a ‘fake’ 10-bpc monitor (Dell 2709W, 8-bpc + FRC) I just leave it in 8-bpc mode, but with HDR and larger colour gamuts becoming more popular (and my next monitor looking to be an ASUS PG27UQ, a real 10-bpc monitor AFAIK) it would be nice to be able to use this feature without breaking random bits of software.
Having 24-bit visuals (either composited or with an overlay) on a depth 30 X screen is something I’ve looked into, but haven’t had a chance to implement. Knowing there’s interest in it helps set priorities.
That said, please be aware that HDR support is much more involved than just using 10-bpc sRGB formats. We’ve started a conversation with the X.Org community on how to properly expose HDR visuals to applications, but HDR at the X11 desktop is still in its infancy.
Thanks for the reply Aaron. I realise that 10-bpc visuals are only part of HDR (I’ve read through Andy’s presentation), but it is a part we have now, where as the other parts are still yet to be developed.
HDR presentation won’t be able to use the existing depth 30 visuals. It’ll have to go through a completely new pixel pipeline. There’s a thread about it that starts here: [RFC] Visual Class for On-Screen HDR Drawables
I understand the need for changes to allow 16-bpc FP Visuals, but what about HDR10 video? That’s specifically Rec.2020 @ 10-bpc (although thinking about it, that’s likely outputted in YUV, rather than RGB which complicates matters).
Either way, you’re still going to want the ability to composite many different colour depth and colour space windows onto one screen. It would be nice if any colour depth worked regardless of what depth the root window/compositor was set to (i.e. be able to create a 10-bpc window, even if only have an 8-bpc output).
I appreciate I’m reviving a 2 and half year old thread here, but I just wanted to say there is still interest in this being supported and that it’s still an issue for Steam. It’s also a problem that is unique to NVidia - AMD just supports this out of the box which might explain why more people aren’t reporting the problem, there is an easy, if not cheap fix.
I expect we may get a fix from Steam long before we get a fix in the driver, but since neither side has come up with a fix in the past 3+ years it surely can’t hurt to push both teams?
I’d like to chime in with interest as well. I’d appreciate having both 30 bit and 24 bit visuals simultaneously rather than having to stop X, switch xorg.conf, and start X.
I have now my first 4k Monitor which is a 30-bit display. I’m also interested to have someday a running steam on it. Also I have seen other visual misbehaviour with Gimp. Gimp is working normally, but there is the same green in the gimp-toolbox like with the steam update window (see github).
Maybe somebody has a solution to become steam started?