9 ms·

> X11 had problems, but instead of fixing them You can't fix a protocol that simply isn't designed for how modern graphics hardware works. Both macOS and Wind

> X11 had problems, but instead of fixing them You can't fix a protocol that simply isn't designed for how modern graphics hardware works. Both macOS and Windows have upgraded their display stacks over the decades, but it was seamless because unlike Linux, nearly all applications dynamically link the system library which they can upgrade. Linux is late to the party here because everyone wants to make their own toolkit. X was designed for multiple remote terminals receiving drawing commands over a network, not locally hardware accelerated graphical interfaces and functions that rely on close coordination between the hardware and display server (e.g. hardware planes, vrr, hdr). Fixing X would require a new protocol to the point that it isn't X anymore, aka Wayland. There are arguments that not having a reference display server has led to problems though.

holowoodman 1y ago
Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought, a separate protocol that is not even all in stable yet. Vulkan usually doesn't work. Latency with Wayland got worse and won't get better because "frames have to be perfect". Tons of unnecessary blitting and latency be damned. All while actually tearing in Wayland is as bad as in X11 here. Fixing X would require a protocol that is mostly X, but of course incompatible because you have to rip out some protocol bugs. But Wayland isn't X minus the bugs. Wayland started as a little bit of broken bitmap-pushing and a whole lot of hot air. And even with tons of extension and auxilliary protocol development, multiplied by tons of unnecessary reimplementations in tons of compositors, it isn't even where X11 was when Wayland started. Wayland fixed nothing yet, broke a lot, fragmented the community, brought pain and misery.
- ChocolateGod 1y ago
  > Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought You don't use Wayland to talk to graphics hardware, you use Wayland to communicate with the display server. The Wayland protocol lets apps negotiate an area to write it output to and how it gets written there is completely up to the application, whether it involves the GPU or not, OpenGL, Vulkan etc. This is in contrast to X where the app use X APIs to draw textures, which are then pulled by the compositor (copy, rip latency/performance), and then sent back to the X server to display.
  - holowoodman 1y ago
    That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between.
    - ChocolateGod 1y ago
      > That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between. This is literally what DRM/DRI is for... which is not Wayland. If you think the display server should handle applications using the GPU, then even Xorg dropped this approach.
- lotharcable 1y ago
  DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X. If you want to get rid of DRM you have to start over and rewrite all graphical drivers for Linux from scratch. DMA is part of the basic architecture of modern computers. It is how you can do things like have fast USB devices or network devices because it allows device hardware to by-pass the CPU and write things directly to memory.
  - holowoodman 1y ago
    > DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X. Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension. > DMA is part of the basic architecture of modern computers. Yes, I know. DMA is even older and not limited to Linux or Graphics. Back in the old VESA, SGI and Windows 3.0 times, DMA was a cool new feature (but actually old even then). When Wayland was conceived, it was boring and old. Yet Wayland didn't originally include DMA buffers, just later added it as an extension when it became obvious that they had just gotten rid of a 40 year old feature that was really really necessary for modern graphics...
    - ChocolateGod 1y ago
      > Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension. DRM is not part of Wayland, and Wayland does not use DRM. Wayland is the protocol between the display server and application, DRM is a functionality provided by the kernel to allow user space applications to use and share graphics hardware. The display server can use DRM, as will applications wanting to use OpenGL/Vulkan, but these are not "wayland".
      - holowoodman 1y ago
        https://wayland.app/protocols/drm-lease-v1 https://wayland.app/protocols/drm-lease-v1
vidarh 1y ago
The protocol is trivially extensible, and have had plenty of extensions that has significant altered how it behaves. Fixing X in a step wise manner wod have been perfectly doable. The problem is that the Wayland proponents didn't just want to fix the things there was agreement was broken, but also wanted to actively break things that would cause an uproar.
- const_cast 1y ago
  But we did do exactly that with X for literal decades. Then the developers of Xorg said "fuck this". I mean, where does the bus stop?
  - vidarh 1y ago
    For literal decades they proved how malleable the protocol is, yes. Then they decided to ignore how malleable the protocol is instead of even trying to e.g. start by deprecating obsolete functionality and disabling it in future versions. When XRender was introduced, for example, was the perfect time to deprecate server-side font-rendering. It's trivial to shim on the client side if anyone cared about the legacy functionality, and it takes a trivial amount of code to switch to using XRender instead for it instead (been there, done that, written a font renderer). There's been plenty of opportunities to gut the legacy parts of the protocol that way, and reduce the complexity. Grouping the main set of extensions and declaring that if the server reports a certain version number or above they
  - LightHugger 1y ago
    This didn't happen because redhat/ibm/microsoft took control of the project and decided they wanted to kill it. They have said this directly on social media that this is their explicit goal so it's not as if this is a conspiracy of some sort, it's just their publicly stated goal. They then deliberately stopped merging changes and left it to rot until the contributors got frustrated enough to fork it. Now a massive gamergate-esque coordinated character assassination campaign against the creator of xlibre is ongoing even from publications that have many previous articles praising the same contributor at length. Corporate control of open source is very dangerous to the ecosystem as they also fund the "journalists" writing these articles who are willing to defend every decision they make.

holowoodman 1y ago

Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought, a separate protocol that is not even all in stable yet. Vulkan usually doesn't work. Latency with Wayland got worse and won't get better because "frames have to be perfect". Tons of unnecessary blitting and latency be damned. All while actually tearing in Wayland is as bad as in X11 here. Fixing X would require a protocol that is mostly X, but of course incompatible because you have to rip out some protocol bugs. But Wayland isn't X minus the bugs. Wayland started as a little bit of broken bitmap-pushing and a whole lot of hot air. And even with tons of extension and auxilliary protocol development, multiplied by tons of unnecessary reimplementations in tons of compositors, it isn't even where X11 was when Wayland started. Wayland fixed nothing yet, broke a lot, fragmented the community, brought pain and misery.

ChocolateGod 1y ago
> Wayland also doesn't even remotely resemble anything that would be fit to talk to modern graphics hardware. DMA buffers and DRM (direct rendering manager, not the digital restrictions management) are an afterthought You don't use Wayland to talk to graphics hardware, you use Wayland to communicate with the display server. The Wayland protocol lets apps negotiate an area to write it output to and how it gets written there is completely up to the application, whether it involves the GPU or not, OpenGL, Vulkan etc. This is in contrast to X where the app use X APIs to draw textures, which are then pulled by the compositor (copy, rip latency/performance), and then sent back to the X server to display.
- holowoodman 1y ago
  That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between.
  - ChocolateGod 1y ago
    > That is complete BS. The application doesn't talk to the graphics hardware alone and then just copy a bitmap into a Wayland buffer. You don't just magically talk to the GPU. There is this little problem called 'security', 'multiprocessing' and 'multiuser' in between. This is literally what DRM/DRI is for... which is not Wayland. If you think the display server should handle applications using the GPU, then even Xorg dropped this approach.
lotharcable 1y ago
DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X. If you want to get rid of DRM you have to start over and rewrite all graphical drivers for Linux from scratch. DMA is part of the basic architecture of modern computers. It is how you can do things like have fast USB devices or network devices because it allows device hardware to by-pass the CPU and write things directly to memory.
- holowoodman 1y ago
  > DRM is literally the 3D acceleration driver framework for Linux. It has been around for decades and is same set of drivers that are used for any sort of accelerated graphics in X. Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension. > DMA is part of the basic architecture of modern computers. Yes, I know. DMA is even older and not limited to Linux or Graphics. Back in the old VESA, SGI and Windows 3.0 times, DMA was a cool new feature (but actually old even then). When Wayland was conceived, it was boring and old. Yet Wayland didn't originally include DMA buffers, just later added it as an extension when it became obvious that they had just gotten rid of a 40 year old feature that was really really necessary for modern graphics...
  - ChocolateGod 1y ago
    > Yes, exactly. And Wayland ignored it for years, from the start, and only later slowly adopted it as an extension. DRM is not part of Wayland, and Wayland does not use DRM. Wayland is the protocol between the display server and application, DRM is a functionality provided by the kernel to allow user space applications to use and share graphics hardware. The display server can use DRM, as will applications wanting to use OpenGL/Vulkan, but these are not "wayland".
    - holowoodman 1y ago
      https://wayland.app/protocols/drm-lease-v1 https://wayland.app/protocols/drm-lease-v1

vidarh 1y ago

The protocol is trivially extensible, and have had plenty of extensions that has significant altered how it behaves. Fixing X in a step wise manner wod have been perfectly doable. The problem is that the Wayland proponents didn't just want to fix the things there was agreement was broken, but also wanted to actively break things that would cause an uproar.

const_cast 1y ago
But we did do exactly that with X for literal decades. Then the developers of Xorg said "fuck this". I mean, where does the bus stop?
- vidarh 1y ago
  For literal decades they proved how malleable the protocol is, yes. Then they decided to ignore how malleable the protocol is instead of even trying to e.g. start by deprecating obsolete functionality and disabling it in future versions. When XRender was introduced, for example, was the perfect time to deprecate server-side font-rendering. It's trivial to shim on the client side if anyone cared about the legacy functionality, and it takes a trivial amount of code to switch to using XRender instead for it instead (been there, done that, written a font renderer). There's been plenty of opportunities to gut the legacy parts of the protocol that way, and reduce the complexity. Grouping the main set of extensions and declaring that if the server reports a certain version number or above they
- LightHugger 1y ago
  This didn't happen because redhat/ibm/microsoft took control of the project and decided they wanted to kill it. They have said this directly on social media that this is their explicit goal so it's not as if this is a conspiracy of some sort, it's just their publicly stated goal. They then deliberately stopped merging changes and left it to rot until the contributors got frustrated enough to fork it. Now a massive gamergate-esque coordinated character assassination campaign against the creator of xlibre is ongoing even from publications that have many previous articles praising the same contributor at length. Corporate control of open source is very dangerous to the ecosystem as they also fund the "journalists" writing these articles who are willing to defend every decision they make.