4 ms·

> I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware. At least on Linux, Xorg and Wayland compositors use the sam

> I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware. At least on Linux, Xorg and Wayland compositors use the same underlying APIs, so the chances of Xorg not running somewhere Wayland runs are pretty much zero - unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it and/or to write a new Xorg driver for the new API.

csande17 3y ago
> unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it And this is actually really unlikely for Wayland, isn't it? The whole idea is that each desktop environment implements its own display server using the modesetting API. That's why there's all kinds of drama about Nvidia "not supporting Wayland"; their kernel driver exposes some nonstandard APIs, and they can patch Xorg to support those APIs, but they can't patch every Wayland compositor in the world. I guess Xorg could hit bugs in the modesetting driver that the most popular Wayland compositors don't hit. IIRC that was an issue for Asahi Linux's Apple M1 video driver.
- badsectoracula 3y ago
  Might be unlikely but not impossible - after all if people cared about not breaking existing software Wayland itself wouldn't exist in the first place :-P Xorg is open source and drivers can be fixed as long as there are enough people to notice and care. Worst case you can run an X root window on top of Wayland compositor and pretend the latter is just a graphics driver :-P.
shmerl 3y ago
> Xorg and Wayland compositors use the same underlying APIs Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasingly simply not bothering to go out of their way with X if something isn't possible to implement over it. So X use case is going to further deteriorate, that's inevitable.
- badsectoracula 3y ago
  > Not really. KWin has Wayland specific paths that simply don't work on X What exactly do you refer to? Note that i meant the kernel APIs to drive the hardware as what i replied to was Xorg not keeping up with newer hardware, not toolkits.
  - shmerl 3y ago
    I mean stuff like bugs with boot screen leaking data not being fixed with X and so on.
    - badsectoracula 3y ago
      How does that have anything to do with X not keeping up with new hardware or using the same kernel APIs as Wayland for communicating with said hardware? What you describe is a minor annoyance at most, not at all on the same level as being unable to use X because of newer hardware. Even if it isn't fixed, one can still be worked around or just ignored, but the other just makes the whole thing literally unusable.
      - shmerl 3y ago
        That means that X case will become increasingly broken. It won't work and won't be supported, newer hardware or not. And X won't have parity for hardware features anyway. Like HDR - it will be Wayland only. And so on and so forth. So X is fried on all ends in the long term. It's not that it's not possible to use kernel interfaces - it's just no one will bother putting an effort in developing X. It's already happening.

csande17 3y ago

> unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it And this is actually really unlikely for Wayland, isn't it? The whole idea is that each desktop environment implements its own display server using the modesetting API. That's why there's all kinds of drama about Nvidia "not supporting Wayland"; their kernel driver exposes some nonstandard APIs, and they can patch Xorg to support those APIs, but they can't patch every Wayland compositor in the world. I guess Xorg could hit bugs in the modesetting driver that the most popular Wayland compositors don't hit. IIRC that was an issue for Asahi Linux's Apple M1 video driver.

badsectoracula 3y ago
Might be unlikely but not impossible - after all if people cared about not breaking existing software Wayland itself wouldn't exist in the first place :-P Xorg is open source and drivers can be fixed as long as there are enough people to notice and care. Worst case you can run an X root window on top of Wayland compositor and pretend the latter is just a graphics driver :-P.

shmerl 3y ago

> Xorg and Wayland compositors use the same underlying APIs Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasingly simply not bothering to go out of their way with X if something isn't possible to implement over it. So X use case is going to further deteriorate, that's inevitable.

badsectoracula 3y ago
> Not really. KWin has Wayland specific paths that simply don't work on X What exactly do you refer to? Note that i meant the kernel APIs to drive the hardware as what i replied to was Xorg not keeping up with newer hardware, not toolkits.
- shmerl 3y ago
  I mean stuff like bugs with boot screen leaking data not being fixed with X and so on.
  - badsectoracula 3y ago
    How does that have anything to do with X not keeping up with new hardware or using the same kernel APIs as Wayland for communicating with said hardware? What you describe is a minor annoyance at most, not at all on the same level as being unable to use X because of newer hardware. Even if it isn't fixed, one can still be worked around or just ignored, but the other just makes the whole thing literally unusable.
    - shmerl 3y ago
      That means that X case will become increasingly broken. It won't work and won't be supported, newer hardware or not. And X won't have parity for hardware features anyway. Like HDR - it will be Wayland only. And so on and so forth. So X is fried on all ends in the long term. It's not that it's not possible to use kernel interfaces - it's just no one will bother putting an effort in developing X. It's already happening.