> So the highest depth you could theoretically go is R10G10B10, and forget about floating-point HDR.

R10G10B10 matches most HDR displays out there, AFAIK even Windows uses that outside of DirectX (where FP16 is used).

But beyond that...

> Fixing this would require rewriting the entire protocol.

...most of the protocol does not have to do with color values. X11 is extensible and an extension can be used that allows alternative functions that use more advanced color values where that'd make sense. For example, assuming you want to use "full" range color values for the drawing functions like XFillPolygon, etc, you'd want to add have the extended range state in graphics contexts, introduce extended commands for changing it (with the existing commands simulating an SDR color for backwards compatibility). That is assuming R10G10B10 is not enough of course (though because for decades many applications assumed 8bit RGB, it is a good idea to do sRGB/SDR simulation for existing APIs and clients regardless of the real underlying mode of the monitor unless a client either opts-in to using extended color or uses the new APIs).

Another thing to keep in mind is that these are really needed if you want to use the draw primitives using extended color / HDR. However most HDR output, at least currently, is either done using some other API (e.g. Vulkan) or via raw pixel data. In which case you need to configure the window output (a window region, to allow for apps with mixed color spaces in a single window - e.g. think Firefox showing a SDR page with an HDR image) to use a specific color space/format and then rely on other APIs for the actual pixel data.

This is something i wanted to look into for a while now, unfortunately other stuff always end up having more priority - and well, my "HDR" monitor is only HDR in name, it barely looks any different when i try to enable HDR mode in KDE Plasma under Wayland for example :-P. I do plan on getting an HDR OLED monitor at some point though and since i do not plan on changing my X11-based environment, i might take a look at it in the future.

▲

bitwize 3 days ago | parent [-]

Again. This is a thing the xorg devs have already looked at. Their conclusion? "Nope. Too much work. Just use Wayland."

Once again, every... last... one of the Xorg devs is of the opinion that you should be using Wayland instead. Even if you had changes to propose to Xorg, they will not make it into a release. If you insist on soldiering on with X, your best bet is probably to contribute to Wayback, likely to be the only supported X11 display server in the near future, and see if you can add a protocol to the compositor to allow "overlay" of an HDR image displayed using Wayland "on top of" an X window that wants to do HDR.

But really, consider switching to Wayland.

▲

johnisgood 3 days ago | parent | next [-]

I wish it was that easy to switch to Wayland, but I have always ran into serious issues. Granted it has been a year since I last tried, so who knows.

I use X11 features such as highlight to copy and then using middle mouse button and/or Shift-Insert to paste its contents (just to mention one), and I use xclip extensively to copy contents of files (and stdin) to it. I use scrot, I use many other applications specifically made for Xorg, and so forth. I have a custom Xorg config as well which may or may not work with Wayland.

Thus, I do not think I could realistically switch to Wayland.

	▲	yjftsjthsd-h 3 days ago \| parent [-]
		> and I use xclip extensively to copy contents of files (and stdin) to it. I won't say anything against your other points (and in fact I am typing this comment on Xorg because I have my own list of reasons), but https://github.com/bugaevc/wl-clipboard is almost drop-in for xclip/xsel.

▲

ryao 2 days ago | parent | prev | next [-]

Please find a quote from this guy agreeing with your remarks:

https://www.x.org/wiki/AlanCoopersmith/

You will not find one.

▲

badsectoracula 2 days ago | parent | prev [-]

> Again. This is a thing the xorg devs have already looked at. Their conclusion? "Nope. Too much work. Just use Wayland."

My comment isn't about how much work something would need, but about how it can be done.

> Once again, every... last... one of the Xorg devs is of the opinion that you should be using Wayland instead.

Good for them, but i have my own opinions.

> Even if you had changes to propose to Xorg, they will not make it into a release.

Maybe or maybe not. AFAICT the official stance has been that nobody wanted to work on these things, not that they are against it, they just do not want to do it themselves.

But if they do not make it into a release, there is also the XLibre fork or there might be other forks in the future, it isn't like Xorg is some sort of proprietary product. I'd rather stick with Xorg as it seems more professional but ultimately whatever works.

> see if you can add a protocol to the compositor to allow "overlay" of an HDR image displayed using Wayland "on top of" an X window that wants to do HDR.

TBH this sounds like an incredibly ugly and fragile hack. There are two main uses for HDR support: embedded HDR (e.g. in a firefox window) and fullscreen HDR (e.g. for videos/games). For the latter there is no point in an overlay, just give the server the full screen. For the former such an overlay will require awful workarounds when you want more than just a self-contained rectangle, e.g. you want it clipped (partially visible image) or need it to be mixed with the underlying contents (think of a non-square HDR shape that blends into SDR text beneath or wrapped around it).

From a pragmatic perspective the best approach would be to see how toolkits, etc, use HDR support in Wayland and implement something similar under X11/Xorg to make supporting both of them easy.

> But really, consider switching to Wayland.

I've been using Window Maker for decades and have no interest in something else. Honestly i think that adding Wayland support to Window Maker or making a Window Maker-like Wayland compositor are both more of an effort and harder than adding HDR support to Xorg. Also i am sometimes trying KDE Plasma Wayland for various things and i have several programs having small but annoying issues under Wayland.

That said, from a practical perspective, one can use both. The only use for HDR i can think of right now is games and videos and i can keep using my Xorg-based setup for everything while switching to another virtual terminal running KDE Plasma Wayland for games/videos that i want to see in HDR. Pressing Ctrl+Alt+Fn to switch virtual terminal isn't any different than pressing Win+n to switch virtual desktop.