[flagged]
Please stop. Let other people have their things. It's disruptive and the kind of behaviour that makes HN toxic.
Meanwhile, X11 works really well for me. No tearing, no artifacts, no breakages on upgrades. Really can’t complain.
Maybe next year.
Every developer who cared about X11 has moved on; it receives little to no maintenance. We already have hardware/software where X11 is entirely unsupported. It's likely we'll see more in the future.
We might get HDR from the Xorg X11 server one day. Once it is in place for everything else, we would just need a X11 extension to hook all of that into X11.
There are NO plans by any of the Xorg maintainers to add HDR support to X11 or the Xorg server, for this reason. There probably never will be.
Window coordinates are worse -- they are INT16s (signed 16-bit integers). So any window, including the root window, can have a maximum size of 32,768x32,768. That's as big a screen as you can get in X11. You sit four 8k monitors next to each other, you start getting close to that hard limit. (Don't dismiss it out of hand. I once worked with a guy who needed no less than five monitors. It was just how he worked. And that's not even addressing things like large wall-sized displays for meetings, war rooms, and the like. Once those start getting high-res, they become beyond X11's ability to handle.) Again, simply extending the protocol won't help -- the protocol must be changed.
Well, while we're changing the protocol, why not do some housekeeping? X11 wasn't designed with security in mind, so let's address that from the jump in our new protocol. Also, modern toolkits do all their rendering client-side, relying on OpenGL or Vulkan to provide GPU-accelerated rendering. All you really need the display server for is to manage the rendering surfaces, composite them together on the final display, and handle user events. So let's start by eliminating all those draw calls from the 1980s that were designed for 1980s displays and not modern GPUs, and pare down the protocol to what's necessary for the above, to avoid bloat and legacy cruft.
Oh shit, we just invented Wayland.
Wayland is the changes to X11 that are necessary in order to move forward.
I have been hearing this for a decade. So far, there is room for both, especially since a number of things work better with the X11 Xorg server. This “everyone should switch to our solution” is like saying everyone should switch to <insert text editor here>. We can have more than 1.
Maybe I'm too old, but i clearly remember SGI supporting more than 8 bits for colour (48 bit ?).
See, for example, the protocol spec for the AllocColor request: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.ht...
Note that the 'pixel' return value, representing the pixel value on the display of the returned color, is a CARD32 (that is, unsigned 32-bit integer).
If you have sources for SGI supporting display of >32bpp images, I'd really like to see them because I'm curious as to how it's done. Note that handling of >32bpp images doesn't count; I can write code that uses any pixel format I like and then convert it to 24bpp or 32bpp for display.