6 ms·

What am I missing? For 99.9% of existing Xorg applications the transition should have been transparent due to the existence of XWayland. In which way was this

What am I missing? For 99.9% of existing Xorg applications the transition should have been transparent due to the existence of XWayland. In which way was this transition the worst for you?

DrillShopper 1y ago
The article talks about the many open issues with Wayland that do not exist in X, if you want some examples.
- mariusor 1y ago
  Which seem to be self inflicted, if I'm not mistaken.
- const_cast 1y ago
  Sure, which are completely solved by Xwayland. If your app doesn't work under Wayland, then fine. Lots of apps don't because they're old and volatile to develop. But X11 apps work completely seamlessly under Wayland. Every major desktop right now is running many X11 apps under Wayland.
  - el_memorioso 1y ago
    I am a Kicad user, not just a random speculator. The problems are not solved by XWayland. For example, Kicad uses different windows to represent different views of the circuit and circuit board and warps the cursor according to the view you are looking at. XWayland doesn't solve this, because it only allows warping within a single window. I know there is new warping code coming out, but I don't know if it will ever get into the LTS OS we use at my work.
    - jchw 1y ago
      The obvious right choice if you're on an LTS OS where Wayland isn't in a good enough shape is to continue using X11 sessions. Very few things are dropping support for X11 right now, and on an LTS OS you presumably would be insulated from that. Obviously you can't benefit from anything Wayland improves on, but I suspect that's not a huge problem. I'd guess an LTS release x years from now would be a different story. Even next year possibly, based on the pace things are going lately.
      - josephcsible 1y ago
        > Obviously you can't benefit from anything Wayland improves on, but I suspect that's not a huge problem. Indeed, that's not a problem at all, because there are zero such things I care about. The problem is that a lot of distros and DE's are dropping support for X even though Wayland still isn't viable at all for so many people, and LTS isn't forever.
        achierius 1y ago
        You're always free to step up and support continued X development. Nobody else wants to, because the code is truly terrible, and that's been the main driver for distributions dropping support.
        jchw 1y ago
        That seems like a solved problem though. LTS distros will drop X11 when the Wayland session is viable for most people, which is very nearly true, but ultimately not. When it does happen, it really shouldn't come as a sudden surprise.
      - lproven 1y ago
        > Very few things are dropping support for X11 right now GNOME 49 will drop X11 sessions completely. That in turn means that the default editions of Ubuntu 25.10 and Fedora 43 drop X11 session support. https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x11/ https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x... Arch will presumably pick up GNOME 49 as soon as it's released, and so GNOME on Arch will also drop X11 session support this (northern hemisphere) autumn. I know that most Ubuntu users run LTS versions, but still, those are probably the 3 most widely-used Linux distros in the Western world, and as such, I think the statement that "very few" things is false where it applies to Linux distros.
        jchw 1y ago
        When I said that, I meant applications and UI toolkits are not dropping X11 support. Non-LTS OSes will definitely be dropping X11 support pretty soon, since yes, KDE and GNOME are both throwing in the towel. To me the timeline seems about right for that too.
    - const_cast 1y ago
      It's such an incredibly niche use case, but nevertheless, I will retract my statement. 99.99% of stuff should work under XWayland.
  - ur-whale 1y ago
    > Sure, which are completely solved by Xwayland. Does Xwayland support running firefox on a remote server and opening it on my local wayland machine ? I'm hoping the answer is yes, because every single time I've tried in the last few years, it failed and it's most definitely NOT a niche feature of X11 for me: I use it all the time.
    - const_cast 1y ago
      I think overall it's a niche feature, and I'm honestly not sure if XWayland allows X forwarding. I know it preserves pretty much all X behavior, including grabbing attention from other windows and such if you give it permission. I don't know how the implementation, specifically, works. Like if each application is under it's own X screen. But, I think if you really rely on X forwarding you should keep using X. The last time I used X forwarding the performance was significantly worse than newer protocols like RDP. X is a very chatty protocol, which performs poorly on a lot of networks.
      - ur-whale 1y ago
        > I think overall it's a niche feature See my comments about Wayland team not listening to their users. It is probably a niche feature FOR THEM. Now, I most certainly agree that X over network is horribly inefficient. However: 1. RDP is a freaking mess on Linux. It may be much better at the protocol level, but all the clients are horrible, and it misbehaves horribly across WANs and/or firewalls. And setting the whole fucking thing up is certainly *way* harder than typing the casual one-liner "export DISPLAY=<ip>:0; firefox&" 2. There is therefore no alternative to X11-over-the-net, and in this 21st century world of everything-in-the-browser enshitification, having to use X11 over the network is something I hit and absolutely rely on about once a week when configuring remote servers.
      - queenkjuul 1y ago
        The performance is worse but the seamlessness of just using SSH to launch a remote app on the local display is incredibly useful when working on headless servers over LAN. Drastically more useful than having to start an entire windowed X11rdp session to run one app for five minutes
  - msgodel 1y ago
    Xwayland has been slow and buggy in my experience. It's very far from seamless. I know one user who stuck with Gnome for decades (he was an "I don't care just get draw the stuff on the screen" kind of guy) until libreoffice became unusable because of the Wayland transition and actually switched back to FVWM over it.
  - bsder 1y ago
    > Sure, which are completely solved by Xwayland. Sadly, they are not. KiCad kicked this press release out because RedHat broke mutter which broke XWayland which caused a whole bunch of us to file bugs against KiCad (and other applications) that were the fault of Wayland. This caused a whole bunch of application developers to have to waste a bunch of time running down a bug that made it completely obvious that RedHat does ZERO testing of whether their changes break anything in the XWayland space.
    - dvdkon 1y ago
      That's not the fault of Wayland, it's a GNOME problem. Wayland being just a protocol has the annoying effect that you get DE-specific bugs. It also means that after switching DEs, you might escape some GNOME-specific bugs. I've been happily using KiCad under XWayland on Sway, I've had no complaints from relatives about the stability of KDE under Wayland, and I hear Hyprland is nice too.
      - bsder 1y ago
        > That's not the fault of Wayland, it's a GNOME problem. You know what ... you're right. Since I'm on an atomic desktop, I shouldn't keep putting up with the abuse. Thanks. I rebased from Silverblue to Kinoite. We'll see how that goes over time.
        bsder 1y ago
        Update since can't edit: Nope. Sadly. Instant dialog box focus problems from kwin_wayland. I switched to kwin_x11 (which KDE doesn't want you to use) and the problems all go away.
- jchw 1y ago
  Some of them are not really "open" issues, which is blatantly obvious if you try to drag a tab in Chrome in KDE or GNOME: The dockable widget use case is covered by xdg-toplevel-drag[1], has been implemented by multiple libraries including Qt 6, and you can fallback to normal drag'n'drop with the downside that the user can't drag the window with the handle. A new protocol was just added for pointer warping[2], too. Not going to lie and say the surface occlusion hanging GL thing isn't annoying, but it is indeed solved by using fifo-v1[3] and commit-timing-v1[4] or the equivalent stop-gap protocols that existed before those ones were merged, since not everything is there yet. Some of these problems even had some workarounds prior to the proper protocols being merged; SDL3 already had a way to warp the pointer by (ab)using the existing pointer constraints API. KiCad for some reason chose to paint the picture that all of these are status quo issues that are not getting solved... but the rate of progress has been pretty good actually. Some of the issues they list are also very blatantly KiCad/wxWidgets issues and not really anything inherently to do with Wayland. Seriously, "Graphical glitches" and "Application freezes and crashes" are not problems caused by your Wayland compositor. [1]: https://wayland.app/protocols/xdg-toplevel-drag-v1 https://wayland.app/protocols/xdg-toplevel-drag-v1 [2]: https://wayland.app/protocols/pointer-warp-v1 https://wayland.app/protocols/pointer-warp-v1 [3]: https://wayland.app/protocols/fifo-v1 https://wayland.app/protocols/fifo-v1 [4]: https://wayland.app/protocols/commit-timing-v1 https://wayland.app/protocols/commit-timing-v1
  - foxylad 1y ago
    You seem knowledgeable in the domain, so I hope you don't mind me picking your brains about the two things stopping me switching to Wayland. 1. Autokey. I use this to expand abbreviations for long words and phrases I use often. This relies on being able to insert itself between the keyboard and all userland apps, and this is apparently impossible under Wayland. 2. SimpleScreenRecorder. This relies on being able to access the window contents for all userland apps, and again this is apprently impossible. Would I be right in thinking that both trip over because Wayland enforces application privacy, so preventing applications accessing other applications resources? And if so, why isn't there a "user root" level for apps that do need to interact with other apps?
    - 1y ago
o11c 1y ago
I just tried out Wayland again on my last install, 1.5 years ago, because I really thought I should give it another chance since people keep saying it finally is supposed to work. My attempt did last longer than previous attempts. But in the end, I gave up due to all the bugs, again. Broken input, broken rendering, broken shortcuts, broken accessibility (not just a thing for those losers who chose to be born disabled) ... it's like Wayland isn't even trying. It's hit-or-miss whether native Wayland programs or XWayland-using programs are more broken. If you want stability and/or features, X11 remains the only choice, even in $CURRENTYEAR. ... actually, it's quite possible that all the X11 devs moving toward Wayland is responsible for the significant decrease in X11 bugs I've seen recently ... or it might just be that there's more RAM. In theory, Wayland is beneficial for the small fraction of users with a high DPI monitor. In practice, if you try to enable it, you get a small fraction of programs that obey it correctly, a moderate fraction of programs that badly mix scaled and unscaled elements, a small fraction of programs that end up double-scaling somehow so everything is too large, and a large fraction of programs that remain tiny. Your machine is much more usable if you just leave everything small and sit closer to the monitor, occasionally using per-app controls that work just as well on X11 anyway. I have not actually seen any other benefits of Wayland, people just tell me they allegedly exist. Sandboxing windows away from each other is pointless since all clients are unsandboxed with the same UID anyway. "All in one process" is exactly the opposite of a feature; it just means that all crashes are fatal instead of usually recoverable like they are on X11. Maybe Wayland should spend a decade or so running its protocol to a server inside X11 first to shake out the bugs?

What am I missing? For 99.9% of existing Xorg applications the transition should have been transparent due to the existence of XWayland. In which way was this transition the worst for you?

DrillShopper 1y ago

The article talks about the many open issues with Wayland that do not exist in X, if you want some examples.

mariusor 1y ago
Which seem to be self inflicted, if I'm not mistaken.
const_cast 1y ago
Sure, which are completely solved by Xwayland. If your app doesn't work under Wayland, then fine. Lots of apps don't because they're old and volatile to develop. But X11 apps work completely seamlessly under Wayland. Every major desktop right now is running many X11 apps under Wayland.
- el_memorioso 1y ago
  I am a Kicad user, not just a random speculator. The problems are not solved by XWayland. For example, Kicad uses different windows to represent different views of the circuit and circuit board and warps the cursor according to the view you are looking at. XWayland doesn't solve this, because it only allows warping within a single window. I know there is new warping code coming out, but I don't know if it will ever get into the LTS OS we use at my work.
  - jchw 1y ago
    The obvious right choice if you're on an LTS OS where Wayland isn't in a good enough shape is to continue using X11 sessions. Very few things are dropping support for X11 right now, and on an LTS OS you presumably would be insulated from that. Obviously you can't benefit from anything Wayland improves on, but I suspect that's not a huge problem. I'd guess an LTS release x years from now would be a different story. Even next year possibly, based on the pace things are going lately.
    - josephcsible 1y ago
      > Obviously you can't benefit from anything Wayland improves on, but I suspect that's not a huge problem. Indeed, that's not a problem at all, because there are zero such things I care about. The problem is that a lot of distros and DE's are dropping support for X even though Wayland still isn't viable at all for so many people, and LTS isn't forever.
      - achierius 1y ago
        You're always free to step up and support continued X development. Nobody else wants to, because the code is truly terrible, and that's been the main driver for distributions dropping support.
      - jchw 1y ago
        That seems like a solved problem though. LTS distros will drop X11 when the Wayland session is viable for most people, which is very nearly true, but ultimately not. When it does happen, it really shouldn't come as a sudden surprise.
    - lproven 1y ago
      > Very few things are dropping support for X11 right now GNOME 49 will drop X11 sessions completely. That in turn means that the default editions of Ubuntu 25.10 and Fedora 43 drop X11 session support. https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x11/ https://www.theregister.com/2025/06/12/ubuntu_2510_to_drop_x... Arch will presumably pick up GNOME 49 as soon as it's released, and so GNOME on Arch will also drop X11 session support this (northern hemisphere) autumn. I know that most Ubuntu users run LTS versions, but still, those are probably the 3 most widely-used Linux distros in the Western world, and as such, I think the statement that "very few" things is false where it applies to Linux distros.
      - jchw 1y ago
        When I said that, I meant applications and UI toolkits are not dropping X11 support. Non-LTS OSes will definitely be dropping X11 support pretty soon, since yes, KDE and GNOME are both throwing in the towel. To me the timeline seems about right for that too.
  - const_cast 1y ago
    It's such an incredibly niche use case, but nevertheless, I will retract my statement. 99.99% of stuff should work under XWayland.
- ur-whale 1y ago
  > Sure, which are completely solved by Xwayland. Does Xwayland support running firefox on a remote server and opening it on my local wayland machine ? I'm hoping the answer is yes, because every single time I've tried in the last few years, it failed and it's most definitely NOT a niche feature of X11 for me: I use it all the time.
  - const_cast 1y ago
    I think overall it's a niche feature, and I'm honestly not sure if XWayland allows X forwarding. I know it preserves pretty much all X behavior, including grabbing attention from other windows and such if you give it permission. I don't know how the implementation, specifically, works. Like if each application is under it's own X screen. But, I think if you really rely on X forwarding you should keep using X. The last time I used X forwarding the performance was significantly worse than newer protocols like RDP. X is a very chatty protocol, which performs poorly on a lot of networks.
    - ur-whale 1y ago
      > I think overall it's a niche feature See my comments about Wayland team not listening to their users. It is probably a niche feature FOR THEM. Now, I most certainly agree that X over network is horribly inefficient. However: 1. RDP is a freaking mess on Linux. It may be much better at the protocol level, but all the clients are horrible, and it misbehaves horribly across WANs and/or firewalls. And setting the whole fucking thing up is certainly *way* harder than typing the casual one-liner "export DISPLAY=<ip>:0; firefox&" 2. There is therefore no alternative to X11-over-the-net, and in this 21st century world of everything-in-the-browser enshitification, having to use X11 over the network is something I hit and absolutely rely on about once a week when configuring remote servers.
    - queenkjuul 1y ago
      The performance is worse but the seamlessness of just using SSH to launch a remote app on the local display is incredibly useful when working on headless servers over LAN. Drastically more useful than having to start an entire windowed X11rdp session to run one app for five minutes
- msgodel 1y ago
  Xwayland has been slow and buggy in my experience. It's very far from seamless. I know one user who stuck with Gnome for decades (he was an "I don't care just get draw the stuff on the screen" kind of guy) until libreoffice became unusable because of the Wayland transition and actually switched back to FVWM over it.
- bsder 1y ago
  > Sure, which are completely solved by Xwayland. Sadly, they are not. KiCad kicked this press release out because RedHat broke mutter which broke XWayland which caused a whole bunch of us to file bugs against KiCad (and other applications) that were the fault of Wayland. This caused a whole bunch of application developers to have to waste a bunch of time running down a bug that made it completely obvious that RedHat does ZERO testing of whether their changes break anything in the XWayland space.
  - dvdkon 1y ago
    That's not the fault of Wayland, it's a GNOME problem. Wayland being just a protocol has the annoying effect that you get DE-specific bugs. It also means that after switching DEs, you might escape some GNOME-specific bugs. I've been happily using KiCad under XWayland on Sway, I've had no complaints from relatives about the stability of KDE under Wayland, and I hear Hyprland is nice too.
    - bsder 1y ago
      > That's not the fault of Wayland, it's a GNOME problem. You know what ... you're right. Since I'm on an atomic desktop, I shouldn't keep putting up with the abuse. Thanks. I rebased from Silverblue to Kinoite. We'll see how that goes over time.
      - bsder 1y ago
        Update since can't edit: Nope. Sadly. Instant dialog box focus problems from kwin_wayland. I switched to kwin_x11 (which KDE doesn't want you to use) and the problems all go away.
jchw 1y ago
Some of them are not really "open" issues, which is blatantly obvious if you try to drag a tab in Chrome in KDE or GNOME: The dockable widget use case is covered by xdg-toplevel-drag[1], has been implemented by multiple libraries including Qt 6, and you can fallback to normal drag'n'drop with the downside that the user can't drag the window with the handle. A new protocol was just added for pointer warping[2], too. Not going to lie and say the surface occlusion hanging GL thing isn't annoying, but it is indeed solved by using fifo-v1[3] and commit-timing-v1[4] or the equivalent stop-gap protocols that existed before those ones were merged, since not everything is there yet. Some of these problems even had some workarounds prior to the proper protocols being merged; SDL3 already had a way to warp the pointer by (ab)using the existing pointer constraints API. KiCad for some reason chose to paint the picture that all of these are status quo issues that are not getting solved... but the rate of progress has been pretty good actually. Some of the issues they list are also very blatantly KiCad/wxWidgets issues and not really anything inherently to do with Wayland. Seriously, "Graphical glitches" and "Application freezes and crashes" are not problems caused by your Wayland compositor. [1]: https://wayland.app/protocols/xdg-toplevel-drag-v1 https://wayland.app/protocols/xdg-toplevel-drag-v1 [2]: https://wayland.app/protocols/pointer-warp-v1 https://wayland.app/protocols/pointer-warp-v1 [3]: https://wayland.app/protocols/fifo-v1 https://wayland.app/protocols/fifo-v1 [4]: https://wayland.app/protocols/commit-timing-v1 https://wayland.app/protocols/commit-timing-v1
- foxylad 1y ago
  You seem knowledgeable in the domain, so I hope you don't mind me picking your brains about the two things stopping me switching to Wayland. 1. Autokey. I use this to expand abbreviations for long words and phrases I use often. This relies on being able to insert itself between the keyboard and all userland apps, and this is apparently impossible under Wayland. 2. SimpleScreenRecorder. This relies on being able to access the window contents for all userland apps, and again this is apprently impossible. Would I be right in thinking that both trip over because Wayland enforces application privacy, so preventing applications accessing other applications resources? And if so, why isn't there a "user root" level for apps that do need to interact with other apps?
  - 1y ago

o11c 1y ago

I just tried out Wayland again on my last install, 1.5 years ago, because I really thought I should give it another chance since people keep saying it finally is supposed to work. My attempt did last longer than previous attempts. But in the end, I gave up due to all the bugs, again. Broken input, broken rendering, broken shortcuts, broken accessibility (not just a thing for those losers who chose to be born disabled) ... it's like Wayland isn't even trying. It's hit-or-miss whether native Wayland programs or XWayland-using programs are more broken. If you want stability and/or features, X11 remains the only choice, even in $CURRENTYEAR. ... actually, it's quite possible that all the X11 devs moving toward Wayland is responsible for the significant decrease in X11 bugs I've seen recently ... or it might just be that there's more RAM. In theory, Wayland is beneficial for the small fraction of users with a high DPI monitor. In practice, if you try to enable it, you get a small fraction of programs that obey it correctly, a moderate fraction of programs that badly mix scaled and unscaled elements, a small fraction of programs that end up double-scaling somehow so everything is too large, and a large fraction of programs that remain tiny. Your machine is much more usable if you just leave everything small and sit closer to the monitor, occasionally using per-app controls that work just as well on X11 anyway. I have not actually seen any other benefits of Wayland, people just tell me they allegedly exist. Sandboxing windows away from each other is pointless since all clients are unsandboxed with the same UID anyway. "All in one process" is exactly the opposite of a feature; it just means that all crashes are fatal instead of usually recoverable like they are on X11. Maybe Wayland should spend a decade or so running its protocol to a server inside X11 first to shake out the bugs?