No. HDR will never come to X11. This is because the X protocol defines a pixel as a CARD32, that is an unsigned 32-bit integer. So the highest depth you could theoretically go is R10G10B10, and forget about floating-point HDR. Fixing this would require rewriting the entire protocol. Which has effectively already been done; it's called Wayland.

Perhaps people ought to listen to the Xorg devs when they say X11 is broken and obsolete, and you should be using Wayland instead. Every single one of them says this.

▲

o11c 4 days ago | parent | next [-]

All sorts of things in X11 are "defined" as a particular thing in the base standard, then changed in protocol extensions. You really shouldn't be writing raw pixels anyway (and most people don't since breaks if your monitor is using 8-bit or 16-bit, for example).

▲

skeezyboy 3 days ago | parent | next [-]

> You really shouldn't be writing raw pixels anyway (and most people don't since breaks if your monitor is using 8-bit or 16-bit, for example).

what are you talking about?

	▲	bitwize 3 days ago \| parent [-]
		X11 supports all sorts of obsolete pixel formats, including 1bpp mono, 4bpp and 8bpp indexed color, and 16bpp "high color" modes. In order to display an image in X11, you need to understand the pixel size, organization, and how colors are mapped to pixel values (all of which are available in a data structure called a visual).

▲

whatevaa 4 days ago | parent | prev [-]

Amazing standard you got there.

	▲	yxhuvud 3 days ago \| parent [-]
		To be fair, the same is very true with Wayland - you can't do much without extensions.

▲

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

> Perhaps people ought to listen to the Xorg devs when they say X11 is broken and obsolete, and you should be using Wayland instead. Every single one of them says this.

This is incorrect. Alan Coopersmith does not share this view and he is a Xorg developer. Anyone repeating this propaganda is arguing from ignorance.

That said, I have used both X11 and Wayland. X11 does its job well in many applications and honestly, we would have been better off had Wayland just been a X11 extension. As for things being broken, I have encountered far more brokenness when using Wayland than when using X11 exclusively. Wayland has gotten better of late, especially in desktop applications, but I do not consider it a replacement in general.

Just recently, I built a display based on a CM4 at work that uses X11 and I can remotely view and interact with the screen using x11vnc, which is fantastic for remote development and debugging. That is a convenience I simply do not have with Wayland. I have tried to do steam remote play by streaming from a desktop to my Steam Deck. If the desktop is running a Wayland session, a pop up appears on the physical display asking if I want to permit remote access and I currently have no way of clicking it without being physically present. This ruins the remote play experience, which I want to use when I am physically not present. A X11 session does not have this problem. If a tool like x11vnc existed for Wayland, it would be useless if it does what Steam Remote Play does with Wayland. :/

	▲	bitwize 9 hours ago \| parent [-]
		> we would have been better off had Wayland just been a X11 extension. That would have never happened. From a functionality standpoint, Wayland is "the parts of X11 modern toolkits actually use". Give clients a buffer, have them locally render into that buffer, then composite the buffers together into a final display. Xorg can do all this. It's just a question of, do we want the maintenance burden of all the other stuff that Xorg has, like obsolete graphics primitives, obsolete visuals, etc.? And do we want the architectural decisions of X11, which seemed sensible in the 80s, but make far less sense in light of modern GPUs and modern applications with modern display needs? The point of Wayland always was to start from scratch.

▲

badsectoracula 4 days ago | parent | prev | next [-]

> 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.

▲

levkk 4 days ago | parent | prev [-]

Sure except Wayland doesn't work with nvidia so...

	▲	whatevaa 4 days ago \| parent [-]
		It works these days.