32 ms·

Or: stable and finished.

rollcat 1y ago
Either that, or a dead end. X11 stayed afloat thanks to the endless extensions, in particular Xcomposite. Windows and OSX have had full modern graphics stacks for 20-25 years, by default. OSX in particular has provided backwards compatibility in a similar fashion as XWayland does (via Carbon). 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.
bitwize 1y ago
Display tech keeps evolving. Proper scaling on HiDPI displays, HDR -- these are things X just doesn't (and will never) have support for because of its architecture. Wayland is the path forward. ALL of the developers who know anything about the display stack have committed to developing for Wayland and deprecating X.
- ryao 1y ago
  I find the Xorg X11 server works just fine with HiDPI displays, while Wayland has issues (mainly just zoom). Alan Coopersmith is not on the Wayland bandwagon as far as I know. 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.
  - bitwize 1y ago
    You can't just bung an extension in to do HDR. You have to change the X11 protocol itself. This is because the X11 protocol was designed way back in the 80s, when it was completely unfathomable that anyone would need more than 32 bits per pixel. So pixel values are CARD32s (unsigned 32-bit integers) in X11. So yeah, I guess theoretically you could do 10-bit-per-channel HDR in the current protocol, but not anything more. And forget about floating point. 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.
    - ryao 1y ago
      > 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.
    - hulitu 1y ago
      > This is because the X11 protocol was designed way back in the 80s, when it was completely unfathomable that anyone would need more than 32 bits per pixel. Maybe I'm too old, but i clearly remember SGI supporting more than 8 bits for colour (48 bit ?).
      - bitwize 1y ago
        That would have been impossible without a display server that supported X plus some other protocol (much like Sun display servers supported both X and NeWS). See, for example, the protocol spec for the AllocColor request: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:AllocColor 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.

Either that, or a dead end. X11 stayed afloat thanks to the endless extensions, in particular Xcomposite. Windows and OSX have had full modern graphics stacks for 20-25 years, by default. OSX in particular has provided backwards compatibility in a similar fashion as XWayland does (via Carbon). 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.

bitwize 1y ago

Display tech keeps evolving. Proper scaling on HiDPI displays, HDR -- these are things X just doesn't (and will never) have support for because of its architecture. Wayland is the path forward. ALL of the developers who know anything about the display stack have committed to developing for Wayland and deprecating X.

ryao 1y ago
I find the Xorg X11 server works just fine with HiDPI displays, while Wayland has issues (mainly just zoom). Alan Coopersmith is not on the Wayland bandwagon as far as I know. 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.
- bitwize 1y ago
  You can't just bung an extension in to do HDR. You have to change the X11 protocol itself. This is because the X11 protocol was designed way back in the 80s, when it was completely unfathomable that anyone would need more than 32 bits per pixel. So pixel values are CARD32s (unsigned 32-bit integers) in X11. So yeah, I guess theoretically you could do 10-bit-per-channel HDR in the current protocol, but not anything more. And forget about floating point. 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.
  - ryao 1y ago
    > 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.
  - hulitu 1y ago
    > This is because the X11 protocol was designed way back in the 80s, when it was completely unfathomable that anyone would need more than 32 bits per pixel. Maybe I'm too old, but i clearly remember SGI supporting more than 8 bits for colour (48 bit ?).
    - bitwize 1y ago
      That would have been impossible without a display server that supported X plus some other protocol (much like Sun display servers supported both X and NeWS). See, for example, the protocol spec for the AllocColor request: https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:AllocColor 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.