10 ms·

Sure X.org is abandonware but there are serious problems Wayland still hasn't solved that X has. 1) Wayland is really slow. I don't know if it's the compositi

by swiley 6y ago

Sure X.org is abandonware but there are serious problems Wayland still hasn't solved that X has. 1) Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on. 2) Widget toolkits handling window decoration is awful. Before the large number of toolkits just meant some controls were a little different but now basic behavior changes based on how programmers decided to build an app. And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use. 3) basic stuff that worked fine on X11 doesn't work on wayland in the name of "security" (screenshots are a big one, there are extensions but isn't that the complaint about X? And if there's a security problem with something isn't hacking around with it because people need it a really strong indication that the idea is broken and probably making the situation worse?)

goatinaboat 6y ago
Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on. This is crazy when you think about it. I remember running an X server, Hummingbird I think it was called, on 386 and 486 machines connecting to Suns and it was fine, this was a perfectly acceptable way to work. Couple of xterms, an Emacs, xbiff for email, maybe some xeyes just for fun. Developing with Tcl/Tk and running those applications. Now we have several orders of magnitude more CPU, memory, network and Wayland doesn't even perform as well as that! My mind is truly boggled.
- Flex247A 6y ago
  What could be the reason behind this? Asking as a noob.
  - beowulfey 6y ago
    I personally don’t know, but most likely when you are not forced to think about memory, efficiency, etc... most people just don’t. So if you aren’t actively developing on those lightweight systems your code won’t run efficiently on them.
    - Flex247A 6y ago
      I guess that explains why Electron based apps don't feel as snappy as native ones.
  - p_l 6y ago
    Part of it is toolkits throwing sometimes multiple megabyte bitmaps to draw, which starts to have problems the moment you don't have a zerocopy, gpu accelerated method to draw them. The old core protocol approach extensively used optimized graphic operations on the server side, with clients sending things like "draw me a rectangle/fill a rectangle/draw a bunch of lines" etc. - today you're going to get pretty big bitmap (especially with high dpi). It's the same problem that mobile devices faced, and is related to a lot of issues on how android devices were "janky" (and related to the various hacks that Apple did to make sure your application wasn't capable of overstressing the early iPhones - cause just displaying basic UI was close to doing that.)
  - goatinaboat 6y ago
    What could be the reason behind this? Asking as a noob Abstractions piled on top of abstractions. Something that might have been 5 function calls deep on either side with a carefully crafted packet in the middle is now 100s on each side. We have a culture that prizes programmer happiness above all and this means everyone thinks "this is a mess, I'll put my own layer on top to make it nice, then work above that layer". Repeat 100 times and now you have processors literally 2000 times faster that struggle to even keep up with keypresses. But what noone wants to admit, is that it's messy because the problem domain is messy and sometimes you just have to live with the mess and get some real work done. The programmers of old understood this.
    - Spooky23 6y ago
      Exactly. There’s no customer, so the product is a nerd carnival that delivers whatever the developers want.
    - adwn 6y ago
      Okay, nice rant, but are too many layers of abstraction the actual cause for Wayland's (alleged?) slowness compared to X? From what I understand, no.
  - Fnoord 6y ago
    The compositor is evil [1] [1] https://news.ycombinator.com/item?id=24466929 https://news.ycombinator.com/item?id=24466929
  - pfortuny 6y ago
    When a window bar needs a gradient, you are starting to stress the graphics engine... And that is just a simple bitmap (or not)...
    - pmarin 6y ago
      http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part-15----Gradients.html http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part...
      - pfortuny 6y ago
        Wow thanks. I was saying that just in order to show the most basic example.
  - Const-me 6y ago
    Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. Windows is using it since Vista. When done right, gradients mentioned in other comments are free, GPUs have hardware to interpolate values (such as colors) across vertices of triangle, for free. Many other effects are either free or very cheap. Engineering-wise it's really hard. Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical). The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens. I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.
    - danaris 6y ago
      > Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. It's great for the common desktop case. It's not as great for some other cases in which Linux is the preferred platform (headless servers, repurposed old hardware, etc). The problem isn't, of course, that there exists a solution for this on Linux. It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.
- folkhack 6y ago
  Yeah - I have no clue why you're being downvoted. I have the exact same professional experience where Wayland is slow out-of-box vs X. I also share the experience of getting X to work on ancient hardware without much difficulty. Let's be real here - if you're needing something to "just work" you're going to install X. Sorry Wayland, you're just not there yet.
  - DyslexicAtheist 6y ago
    > Yeah - I have no clue why you're being downvoted. I didn't downvote but it's because parents comment are anecdotal and not providing further data one might be able to engage/confirm/refute ... and therefore I learned nothing from reading it. I'm also running a dual setup of i3/sway and the only reason why I still keep i3 around is screen-sharing in jitsi and similar. and my experience is that wayland has a lower use of CPU/memory than when running X (i3) but it's not why I prefer sway. (I'm using sway with "xwayland disable" so maybe this is where a lot of resources are saved). But the whole discussion is pointless without verifiable benchmarks.
    - asveikau 6y ago
      Well, the anecdotes are kind of real, and vast in numbers. I suspect many readers here never used X on a 90s PC or workstation, so they could be forgiven for not realizing it was up to the task on hardware that is now pitiful. Another example I like is the Nokia N900, which ran X on a phone no less, phone hardware from 2009, and it was pretty good there. Part of the problem is surely software bloat over time on higher parts of the stack, rather than X itself. You couldn't get the 486 in the comment above to run recent gnome or a recent browser. But you could run software of the era well.
    - tutfbhuf 6y ago
      Maybe someone could try to install Wayland on an old device, where latest Xorg works fast, and see if Wayland also does. Comparison video would be nice.
- gnufx 6y ago
  For what it's worth, Exceed was never fine in my experience, and you were better off with the Cygwin server. At one time, the first thing to ask about certain sorts of Emacs problems that were reported was "Are you running Exceed?", with high probability the answer would be "Yes". I never understood why "we" paid for it. But, yes, X did always run on relatively low-resource machines. (I can't comment on how Wayland compares.)
- adwn 6y ago
  For what it's worth, whenever I tunneled X over a non-local SSH connection, it was slow as molasses. That's because almost all contemporary GUI applications render to a bitmap anyway. Those that actually use the outdated X vector graphics operations look like utter garbage compared to anything post-1995. Frankly, I'd rather my applications are at least somewhat aesthetically pleasing.
  - jleahy 6y ago
    I routinely use modern X applications running on a remote (25 miles) machine, all day long as part of my job. It works flawlessly if you have a reasonable amount of bandwidth and reasonable latency. Sure, it doesn’t work over dial-up.
    - MayeulC 6y ago
      Honestly, X forwarding doesn't work that well in my experience, unless you have a very stable connection, with quite a bit of bandwidth (~1Mbps at the very least). I've had more success using xpra for forwarding, as I'm often connecting over Wi-Fi (hostel, campus rooms...). It's also rather complicated to set-up on the server side (xauth, magic cookie, etc). waypipe, on the other hand, was a breeze to use, even though it's very young. I tried with Firefox and 500Mbps of upload capacity, it worked fine as long as the window wasn't too large.
      - ajsnigrutin 6y ago
        > It's also rather complicated to set-up on the server side (xauth, magic cookie, etc). you mean "ssh -Y user@host..."?
        MayeulC 6y ago
        No, that is the client side. I went back and looked at the documentation, I was wrong and conflated two ways of doing it: - X forwarding over SSH: this only requires changing X11Forwarding in OpenSSH sshd's config - Plain X over network, which is secured with `xhost`, insecure, and needs transfering the magic cookie or other authentication information So, not nearly as complex to setup as I recalled, though it's much simpler to run a nested wayland compositor (which waypipe does) than a X11 server (which xpra does). The difference between X11 and Wayland remote access thins when xpra is involved. https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie https://stackoverflow.com/questions/37157097/how-does-x11-au...
- flyinghamster 6y ago
  I think much of the problem is that today's systems have vast amounts of eye candy that was all but nonexistent back in the 80s and 90s. X terminals and 486s don't have the resources to throwing fancy visual effects on the screen, and sometimes might not even be color displays.
- pmontra 6y ago
  Anecdotally I run X11 on several Sun workstations (Motorola 680xx), a Dec Alpha (some RISC), HP X terminals, etc. All of them were reasonably fast or at least not any slower than the Windows and Mac boxes of the time (1990/95.) We played videogames on them. Does anybody remember Netrek, Xtanks, and a F16 vs MIG flight simulator which I can't remember the name of?
- swiley 6y ago
  I feel like I should point out I was thinking of my 64bit core-i5 machine when I made that comment. A 386 won't even run a modern Linux kernel.
solarkraft 6y ago
> Wayland is really slow. I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast. > And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use. No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say. > basic stuff that worked fine on X11 doesn't work on wayland in the name of "security" On only the core Wayland protocols you're absolutely correct, you can't even implement desktop shells with those. This means there must be extensions and there are 3 different classes: KDE, GNOME, wlroots, with tools for and incompatibility between each. The wlroots extensions are designed to be accepted into the standard and for wider Wayland acceptance they probably should be. Screen sharing is still a particular issue that we are starting to see solved with the advent of Pipewire. Wayland desktops are definitely usable. I've been happy with a wlroots based one (Wayfire) for a few months and KDE before that (from what I see GNOME has been perfect for a while). One of the last standing real issues I'm facing is kerfuffle with Nvidia drivers, especially the ones paired with Intel GPUs, but I think (surprisingly) Nvidia are actually working on fixing that.
- mort96 6y ago
  > No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say. The compositor can implement that protocol and just respond with "this compositor doesn't support SSDs". GNOME does this, so all toolkits must use CSDs if they wanna work on the most popular Wayland compositor. Incidentally, that's hell for all the simple libraries out there which just exist to get a GL window on the screen. GLFW, GLEW, SDL, etc. all have to implement CSDs now if they wanna work with Wayland. It also means that it's no longer feasible to just make a Linux application which uses the windowing system directly; everything must use a huge toolkit now. EDIT: To clarify, I don't think this is an issue with Wayland, but with GNOME. There's no reason it couldn't have supported SSDs like every other Wayland compositor. But as it stands, it hurts the Wayland ecosystem.
  - cycloptic 6y ago
deleted 6y ago
[deleted]
SweetestRug 6y ago
> Wayland is really slow I have to wonder if this is distribution dependent? On Manjaro my experience with Wayland has been fantastic. I cannot perceive any speed differences vs X.org; Wayland just flies. It would be interesting to poll users and see just what factors are contributing to speed issues. GPU? CPU? Distribution? Wlroots vs Gnome? etc. Learning more about what users experience could be helpful in making Wayland better. Has anyone done this?
- ironmagma 6y ago
  This is a great idea. So many Linux issues go undiagnosed because the response is so often “it works fine for me, on my <insert insanely overpowered system specs here>.”
- microcolonel 6y ago
  Yeah, I think there are a lot of distro bugs, and a lot of old or mismatched packages, outside of the Arch/Manjaro ecosystem. This hurts the impression of Mesa, the Kernel, and basically anything else like this where there's no good reason conventional distros shouldn't ship new feature releases at least a bit more frequently than they do.
- sergeykish 6y ago
  I've found GamingOnLinux statistics [1]. Mostly X11, wayland 7%. But look at the other data: * Both Ubuntu and Arch based distro 40% * Manjaro helped a lot 15% * Both AMD and Intel 50% * AMD GPU 40% and rising * Open source GPU driver 43% (almost all of it AMD) * 10% own VR Headset [1] https://www.gamingonlinux.com/index.php?module=statistics&view=trends https://www.gamingonlinux.com/index.php?module=statistics&vi...
linuxdaemon 6y ago
I am forced to use ms teams for work. Every time I attempted to share my desktop, teams would crash. I thought it was just because teams sucks. As it turns out, it seems to be that running under wayland was actually causing it. Everything works fine under x.org. After I was running with x.org for a couple days, I realized there are quite a few little oddities that I just lived with and didn't realize it was because wayland was actually messing things up.
- Arnavion 6y ago
  Yes, Teams uses a function that is unsupported by Xwayland (XGetImage, if I remember the backtrace correctly), so it crashes. I worked around it with a rather convoluted setup that involves running Xephyr under Xwayland, then running Teams under Xephyr (via setting `DISPLAY`), and running vncviewer under Xephyr connected to a VNC server (wayvnc) sharing my screen on the parent wayland instance. Then I tell Teams to share the "whole screen" (ie the entire Xephyr window) and quickly maximize the vncviewer window (within the Xephyr window). To be able to maximize vncviewer you do need a compositor running under Xephyr too. I picked i3 to be the most minimal. Again, i3 can be told to run in the Xephyr window by setting `DISPLAY`. One caveat is that I still use Teams under Wayland to join calls for the audio, so this setup means I need two Teams instances to join the same call. This works for meetings but not for individual calls. Of course if you want to use the Xephyr'd Teams to do audio too there shouldn't be any problem; I just prefer having easy access to the Teams window to mute myself, etc instead of having to reach into the Xephyr window and unmaximize the vncviewer window. People on the #sway IRC channel on Freenode suggested an alternative might be to use v4l2loopback to create a "camera" device that is sourced from the screen and then have Teams use it as a webcam, but I couldn't get v4l2 to work on my distro (it kept insisting my distro's ffmpeg couldn't encode video even though it could) so I didn't investigate further.
  - michaelmrose 6y ago
    I salute your creativity and tenacity but what the actual fuck the need for a rube goldberg setup in order to make an application work is ... unfortunate. If I did such a thing I would take one last look to take pride in my work before deleting the whole affair and installing an OS that isn't broken.
blibble 6y ago
> Wayland is really slow. as a counterpoint: my sway (Wayland) system is the first one I've ever had where I can watch youtube, or vlc/mpv at 60fps without flickering, dropping frames or tearing I've used nvidia and radeon cards, plus intel onboard in this machine with X and none of them allowed all of the above the display server also remains responsive even if one client starts going nuts generally sway is considerably more responsive on the same system than the Xorg it replaced I am very happy with it
- tutfbhuf 6y ago
  > first one I've ever had where I can watch youtube, or vlc/mpv at 60fps without flickering, dropping frames or tearing Have you tried Picom? https://wiki.archlinux.org/index.php/Picom https://wiki.archlinux.org/index.php/Picom
- jjt-yn_t 6y ago
  Unclear which hardware you have working with sway?
circlingthesun 6y ago
It apparently also lacks good color management. https://www.reddit.com/r/wayland/comments/ihi1wm/xwayland_over_saturated_colors https://www.reddit.com/r/wayland/comments/ihi1wm/xwayland_ov...
pengaru 6y ago
> 1) Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on. Presumably your compositor is using llvmpipe software rendering if it's so slow. Unaccelerated Xorg using something like the vesa driver is slow too.
- swiley 6y ago
  I own machines that have no hardware acceleration (I had to remove the kernel modules and use the efi framebuffer because the drivers would crash.) Xorg is absolutely usable on such machines with compositing disabled, wayland is not.
  - pengaru 6y ago
    > Xorg is absolutely usable on such machines with compositing disabled, wayland is not. For this comparison to make any sense at all you need to state which Wayland compositor, Wayland is a protocol.
derefr 6y ago
> And if there's a security problem with something isn't hacking around with it because people need it a really strong indication that the idea is broken and probably making the situation worse? If there’s a security problem and people are hacking around it, that’s an indication that the either those people have bad needs, or that the security model is flawed — but it’s not an indication that it’s wrong to attempt to secure that resource in the first place. If a janitor needs the nuclear-missile launch codes to clean the missile silo, you’ve probably fucked something up — but that “something” isn’t the fact that the missile silo doors are code-locked. (Instead, it’s probably 1. the fact that you’re using the same credentials for physical missile access as you are for missile launch, and 2. the fact that your regular janitor is expected to clean the missile silo.) In this case, the security model of Wayland is the same kind that Windows and Android already have: preventing “low-integrity” apps from screen-scraping “high-integrity” apps. In other words, preventing a random webpage running in Chrome from stealing your credit card details sitting visibly in a sibling text-editor window. (Or, of course, preventing you from Twitch-streaming your playback of DRMed Netflix video. That’s a use-case that “needs supporting” too, given that the alternative is that type of video not playing back on the platform at all.)
- danaris 6y ago
  I guess my question is: Why shouldn't "take a screenshot, either of a window, the whole screen, or a portion of the screen" be something that Wayland itself be expected to handle? I mean, if you're worried about security of apps from other apps, don't make it something in the apps' domain. Only allow Wayland to take the screenshots, but support that, make it easy, and you won't need to worry about either the security model or users complaining. I mean, this is the way other OSes do it...to the best of my knowledge (which is certainly not comprehensive) neither Windows nor macOS allow arbitrary apps to screenshot arbitrary portions of the screen; that's handled by the OS itself.
  - derefr 6y ago
    I think that (the compositor doing the screenshotting) is already the way it works. But "screenshots" (i.e. fed to the user as files / on the pasteboard) are the exception, not the rule, of the use of this API. The normal, non-edge-case use of the relevant screen-capturing API is for screen-sharing ala Zoom, or for remote desktop using RDP et al. These are use-cases where one app wants to see what's going on in other apps — exactly the thing you wouldn't want a malicious app to be able to do, but also exactly the thing that you do want these apps to be able to do.

by swiley 6y ago

goatinaboat 6y ago

Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on. This is crazy when you think about it. I remember running an X server, Hummingbird I think it was called, on 386 and 486 machines connecting to Suns and it was fine, this was a perfectly acceptable way to work. Couple of xterms, an Emacs, xbiff for email, maybe some xeyes just for fun. Developing with Tcl/Tk and running those applications. Now we have several orders of magnitude more CPU, memory, network and Wayland doesn't even perform as well as that! My mind is truly boggled.

Flex247A 6y ago
What could be the reason behind this? Asking as a noob.
- beowulfey 6y ago
  I personally don’t know, but most likely when you are not forced to think about memory, efficiency, etc... most people just don’t. So if you aren’t actively developing on those lightweight systems your code won’t run efficiently on them.
  - Flex247A 6y ago
    I guess that explains why Electron based apps don't feel as snappy as native ones.
- p_l 6y ago
  Part of it is toolkits throwing sometimes multiple megabyte bitmaps to draw, which starts to have problems the moment you don't have a zerocopy, gpu accelerated method to draw them. The old core protocol approach extensively used optimized graphic operations on the server side, with clients sending things like "draw me a rectangle/fill a rectangle/draw a bunch of lines" etc. - today you're going to get pretty big bitmap (especially with high dpi). It's the same problem that mobile devices faced, and is related to a lot of issues on how android devices were "janky" (and related to the various hacks that Apple did to make sure your application wasn't capable of overstressing the early iPhones - cause just displaying basic UI was close to doing that.)
- goatinaboat 6y ago
  What could be the reason behind this? Asking as a noob Abstractions piled on top of abstractions. Something that might have been 5 function calls deep on either side with a carefully crafted packet in the middle is now 100s on each side. We have a culture that prizes programmer happiness above all and this means everyone thinks "this is a mess, I'll put my own layer on top to make it nice, then work above that layer". Repeat 100 times and now you have processors literally 2000 times faster that struggle to even keep up with keypresses. But what noone wants to admit, is that it's messy because the problem domain is messy and sometimes you just have to live with the mess and get some real work done. The programmers of old understood this.
  - Spooky23 6y ago
    Exactly. There’s no customer, so the product is a nerd carnival that delivers whatever the developers want.
  - adwn 6y ago
    Okay, nice rant, but are too many layers of abstraction the actual cause for Wayland's (alleged?) slowness compared to X? From what I understand, no.
- Fnoord 6y ago
  The compositor is evil [1] [1] https://news.ycombinator.com/item?id=24466929 https://news.ycombinator.com/item?id=24466929
- pfortuny 6y ago
  When a window bar needs a gradient, you are starting to stress the graphics engine... And that is just a simple bitmap (or not)...
  - pmarin 6y ago
    http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part-15----Gradients.html http://xopendisplay.hilltopia.ca/2009/Jul/Xlib-tutorial-part...
    - pfortuny 6y ago
      Wow thanks. I was saying that just in order to show the most basic example.
- Const-me 6y ago
  Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. Windows is using it since Vista. When done right, gradients mentioned in other comments are free, GPUs have hardware to interpolate values (such as colors) across vertices of triangle, for free. Many other effects are either free or very cheap. Engineering-wise it's really hard. Microsoft reworked GPU driver model introducing WDDM. They invented a new user-facing API for that, introducing Direct3D 10. They did that in close collaboration with all 3 GPU vendors. They made user-mode components like desktop compositor itself, dwm.exe, and higher-level libraries to benefit from all that stuff. Initially they were optional things like WPF, Direct2D, DirectWrite, then with Win8 they introduced WinRT later rebranded to UWP. That one is no longer optional and is the only practical way to render "hello world, GUI edition" in modern Windows (possible to do with DirectWrite or legacy GDI but neither of them is practical). The problem "render nice high-resolution graphics, fast" affects everything, the entire stack. Modern Linux has decent kernel infrastructure (DRM/KMS), but even so, remaining challenges are hard. Linux has less luck with user-facing GPU APIs (Vulkan is not yet universally available, neither is GLES3+ or OpenGL 4.3+). For some GPUs, quality of drivers is less than ideal. OS maintainers oppose stabilizing kernel ABI for drivers. There's no high level GPU-centric graphics libraries, I tried once with moderate success https://github.com/Const-me/Vrmac https://github.com/Const-me/Vrmac but that only supports one specific Debian Linux on one specific computer which happens to support GLES 3.1, and some important features are missing e.g. no gradient brushes or stroked pens. I don't see any large party interested in making that happen. At least not for desktop Linux. Valve started to do relevant things when they thought Windows 10 is going to kill their Steam business model, then it became apparent Microsoft won't make Win10 into an iOS-style walled garden, and they no longer have much motivation.
  - danaris 6y ago
    > Technically what Wayland is doing, using 3D GPU for everything, is the best way forward. It's great for the common desktop case. It's not as great for some other cases in which Linux is the preferred platform (headless servers, repurposed old hardware, etc). The problem isn't, of course, that there exists a solution for this on Linux. It's that that solution is being pushed as the only one that should be maintained—and thus, exist—going forward.
folkhack 6y ago
Yeah - I have no clue why you're being downvoted. I have the exact same professional experience where Wayland is slow out-of-box vs X. I also share the experience of getting X to work on ancient hardware without much difficulty. Let's be real here - if you're needing something to "just work" you're going to install X. Sorry Wayland, you're just not there yet.
- DyslexicAtheist 6y ago
  > Yeah - I have no clue why you're being downvoted. I didn't downvote but it's because parents comment are anecdotal and not providing further data one might be able to engage/confirm/refute ... and therefore I learned nothing from reading it. I'm also running a dual setup of i3/sway and the only reason why I still keep i3 around is screen-sharing in jitsi and similar. and my experience is that wayland has a lower use of CPU/memory than when running X (i3) but it's not why I prefer sway. (I'm using sway with "xwayland disable" so maybe this is where a lot of resources are saved). But the whole discussion is pointless without verifiable benchmarks.
  - asveikau 6y ago
    Well, the anecdotes are kind of real, and vast in numbers. I suspect many readers here never used X on a 90s PC or workstation, so they could be forgiven for not realizing it was up to the task on hardware that is now pitiful. Another example I like is the Nokia N900, which ran X on a phone no less, phone hardware from 2009, and it was pretty good there. Part of the problem is surely software bloat over time on higher parts of the stack, rather than X itself. You couldn't get the 486 in the comment above to run recent gnome or a recent browser. But you could run software of the era well.
  - tutfbhuf 6y ago
    Maybe someone could try to install Wayland on an old device, where latest Xorg works fast, and see if Wayland also does. Comparison video would be nice.
gnufx 6y ago
For what it's worth, Exceed was never fine in my experience, and you were better off with the Cygwin server. At one time, the first thing to ask about certain sorts of Emacs problems that were reported was "Are you running Exceed?", with high probability the answer would be "Yes". I never understood why "we" paid for it. But, yes, X did always run on relatively low-resource machines. (I can't comment on how Wayland compares.)
adwn 6y ago
For what it's worth, whenever I tunneled X over a non-local SSH connection, it was slow as molasses. That's because almost all contemporary GUI applications render to a bitmap anyway. Those that actually use the outdated X vector graphics operations look like utter garbage compared to anything post-1995. Frankly, I'd rather my applications are at least somewhat aesthetically pleasing.
- jleahy 6y ago
  I routinely use modern X applications running on a remote (25 miles) machine, all day long as part of my job. It works flawlessly if you have a reasonable amount of bandwidth and reasonable latency. Sure, it doesn’t work over dial-up.
  - MayeulC 6y ago
    Honestly, X forwarding doesn't work that well in my experience, unless you have a very stable connection, with quite a bit of bandwidth (~1Mbps at the very least). I've had more success using xpra for forwarding, as I'm often connecting over Wi-Fi (hostel, campus rooms...). It's also rather complicated to set-up on the server side (xauth, magic cookie, etc). waypipe, on the other hand, was a breeze to use, even though it's very young. I tried with Firefox and 500Mbps of upload capacity, it worked fine as long as the window wasn't too large.
    - ajsnigrutin 6y ago
      > It's also rather complicated to set-up on the server side (xauth, magic cookie, etc). you mean "ssh -Y user@host..."?
      - MayeulC 6y ago
        No, that is the client side. I went back and looked at the documentation, I was wrong and conflated two ways of doing it: - X forwarding over SSH: this only requires changing X11Forwarding in OpenSSH sshd's config - Plain X over network, which is secured with `xhost`, insecure, and needs transfering the magic cookie or other authentication information So, not nearly as complex to setup as I recalled, though it's much simpler to run a nested wayland compositor (which waypipe does) than a X11 server (which xpra does). The difference between X11 and Wayland remote access thins when xpra is involved. https://stackoverflow.com/questions/37157097/how-does-x11-authorization-works-mit-magic-cookie https://stackoverflow.com/questions/37157097/how-does-x11-au...
flyinghamster 6y ago
I think much of the problem is that today's systems have vast amounts of eye candy that was all but nonexistent back in the 80s and 90s. X terminals and 486s don't have the resources to throwing fancy visual effects on the screen, and sometimes might not even be color displays.
pmontra 6y ago
Anecdotally I run X11 on several Sun workstations (Motorola 680xx), a Dec Alpha (some RISC), HP X terminals, etc. All of them were reasonably fast or at least not any slower than the Windows and Mac boxes of the time (1990/95.) We played videogames on them. Does anybody remember Netrek, Xtanks, and a F16 vs MIG flight simulator which I can't remember the name of?
swiley 6y ago
I feel like I should point out I was thinking of my 64bit core-i5 machine when I made that comment. A 386 won't even run a modern Linux kernel.

solarkraft 6y ago

> Wayland is really slow. I think you don't mean that the Wayland protocol forces slowness but that the compositor you used was slow. The one I use is fast. > And if you don't like the window decorations (say, they take up too much screen space) your choices are suck it up, or if you're lucky and willing to spend a bunch of time reconfigure every different toolkit your apps use. No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say. > basic stuff that worked fine on X11 doesn't work on wayland in the name of "security" On only the core Wayland protocols you're absolutely correct, you can't even implement desktop shells with those. This means there must be extensions and there are 3 different classes: KDE, GNOME, wlroots, with tools for and incompatibility between each. The wlroots extensions are designed to be accepted into the standard and for wider Wayland acceptance they probably should be. Screen sharing is still a particular issue that we are starting to see solved with the advent of Pipewire. Wayland desktops are definitely usable. I've been happy with a wlroots based one (Wayfire) for a few months and KDE before that (from what I see GNOME has been perfect for a while). One of the last standing real issues I'm facing is kerfuffle with Nvidia drivers, especially the ones paired with Intel GPUs, but I think (surprisingly) Nvidia are actually working on fixing that.

mort96 6y ago
> No, there are protocols to negotiate whether an app has server side decoration or not and the compositor has the last say. The compositor can implement that protocol and just respond with "this compositor doesn't support SSDs". GNOME does this, so all toolkits must use CSDs if they wanna work on the most popular Wayland compositor. Incidentally, that's hell for all the simple libraries out there which just exist to get a GL window on the screen. GLFW, GLEW, SDL, etc. all have to implement CSDs now if they wanna work with Wayland. It also means that it's no longer feasible to just make a Linux application which uses the windowing system directly; everything must use a huge toolkit now. EDIT: To clarify, I don't think this is an issue with Wayland, but with GNOME. There's no reason it couldn't have supported SSDs like every other Wayland compositor. But as it stands, it hurts the Wayland ecosystem.
- cycloptic 6y ago

deleted 6y ago

[deleted]

SweetestRug 6y ago

> Wayland is really slow I have to wonder if this is distribution dependent? On Manjaro my experience with Wayland has been fantastic. I cannot perceive any speed differences vs X.org; Wayland just flies. It would be interesting to poll users and see just what factors are contributing to speed issues. GPU? CPU? Distribution? Wlroots vs Gnome? etc. Learning more about what users experience could be helpful in making Wayland better. Has anyone done this?

ironmagma 6y ago
This is a great idea. So many Linux issues go undiagnosed because the response is so often “it works fine for me, on my <insert insanely overpowered system specs here>.”
microcolonel 6y ago
Yeah, I think there are a lot of distro bugs, and a lot of old or mismatched packages, outside of the Arch/Manjaro ecosystem. This hurts the impression of Mesa, the Kernel, and basically anything else like this where there's no good reason conventional distros shouldn't ship new feature releases at least a bit more frequently than they do.
sergeykish 6y ago
I've found GamingOnLinux statistics [1]. Mostly X11, wayland 7%. But look at the other data: * Both Ubuntu and Arch based distro 40% * Manjaro helped a lot 15% * Both AMD and Intel 50% * AMD GPU 40% and rising * Open source GPU driver 43% (almost all of it AMD) * 10% own VR Headset [1] https://www.gamingonlinux.com/index.php?module=statistics&view=trends https://www.gamingonlinux.com/index.php?module=statistics&vi...

linuxdaemon 6y ago

I am forced to use ms teams for work. Every time I attempted to share my desktop, teams would crash. I thought it was just because teams sucks. As it turns out, it seems to be that running under wayland was actually causing it. Everything works fine under x.org. After I was running with x.org for a couple days, I realized there are quite a few little oddities that I just lived with and didn't realize it was because wayland was actually messing things up.

Arnavion 6y ago
Yes, Teams uses a function that is unsupported by Xwayland (XGetImage, if I remember the backtrace correctly), so it crashes. I worked around it with a rather convoluted setup that involves running Xephyr under Xwayland, then running Teams under Xephyr (via setting `DISPLAY`), and running vncviewer under Xephyr connected to a VNC server (wayvnc) sharing my screen on the parent wayland instance. Then I tell Teams to share the "whole screen" (ie the entire Xephyr window) and quickly maximize the vncviewer window (within the Xephyr window). To be able to maximize vncviewer you do need a compositor running under Xephyr too. I picked i3 to be the most minimal. Again, i3 can be told to run in the Xephyr window by setting `DISPLAY`. One caveat is that I still use Teams under Wayland to join calls for the audio, so this setup means I need two Teams instances to join the same call. This works for meetings but not for individual calls. Of course if you want to use the Xephyr'd Teams to do audio too there shouldn't be any problem; I just prefer having easy access to the Teams window to mute myself, etc instead of having to reach into the Xephyr window and unmaximize the vncviewer window. People on the #sway IRC channel on Freenode suggested an alternative might be to use v4l2loopback to create a "camera" device that is sourced from the screen and then have Teams use it as a webcam, but I couldn't get v4l2 to work on my distro (it kept insisting my distro's ffmpeg couldn't encode video even though it could) so I didn't investigate further.
- michaelmrose 6y ago
  I salute your creativity and tenacity but what the actual fuck the need for a rube goldberg setup in order to make an application work is ... unfortunate. If I did such a thing I would take one last look to take pride in my work before deleting the whole affair and installing an OS that isn't broken.

blibble 6y ago

> Wayland is really slow. as a counterpoint: my sway (Wayland) system is the first one I've ever had where I can watch youtube, or vlc/mpv at 60fps without flickering, dropping frames or tearing I've used nvidia and radeon cards, plus intel onboard in this machine with X and none of them allowed all of the above the display server also remains responsive even if one client starts going nuts generally sway is considerably more responsive on the same system than the Xorg it replaced I am very happy with it

tutfbhuf 6y ago
> first one I've ever had where I can watch youtube, or vlc/mpv at 60fps without flickering, dropping frames or tearing Have you tried Picom? https://wiki.archlinux.org/index.php/Picom https://wiki.archlinux.org/index.php/Picom
jjt-yn_t 6y ago
Unclear which hardware you have working with sway?

circlingthesun 6y ago

It apparently also lacks good color management. https://www.reddit.com/r/wayland/comments/ihi1wm/xwayland_over_saturated_colors https://www.reddit.com/r/wayland/comments/ihi1wm/xwayland_ov...

pengaru 6y ago

> 1) Wayland is really slow. I don't know if it's the compositing or what but it's unusable on lighter hardware that X ran fine on. Presumably your compositor is using llvmpipe software rendering if it's so slow. Unaccelerated Xorg using something like the vesa driver is slow too.

swiley 6y ago
I own machines that have no hardware acceleration (I had to remove the kernel modules and use the efi framebuffer because the drivers would crash.) Xorg is absolutely usable on such machines with compositing disabled, wayland is not.
- pengaru 6y ago
  > Xorg is absolutely usable on such machines with compositing disabled, wayland is not. For this comparison to make any sense at all you need to state which Wayland compositor, Wayland is a protocol.

derefr 6y ago

> And if there's a security problem with something isn't hacking around with it because people need it a really strong indication that the idea is broken and probably making the situation worse? If there’s a security problem and people are hacking around it, that’s an indication that the either those people have bad needs, or that the security model is flawed — but it’s not an indication that it’s wrong to attempt to secure that resource in the first place. If a janitor needs the nuclear-missile launch codes to clean the missile silo, you’ve probably fucked something up — but that “something” isn’t the fact that the missile silo doors are code-locked. (Instead, it’s probably 1. the fact that you’re using the same credentials for physical missile access as you are for missile launch, and 2. the fact that your regular janitor is expected to clean the missile silo.) In this case, the security model of Wayland is the same kind that Windows and Android already have: preventing “low-integrity” apps from screen-scraping “high-integrity” apps. In other words, preventing a random webpage running in Chrome from stealing your credit card details sitting visibly in a sibling text-editor window. (Or, of course, preventing you from Twitch-streaming your playback of DRMed Netflix video. That’s a use-case that “needs supporting” too, given that the alternative is that type of video not playing back on the platform at all.)

danaris 6y ago
I guess my question is: Why shouldn't "take a screenshot, either of a window, the whole screen, or a portion of the screen" be something that Wayland itself be expected to handle? I mean, if you're worried about security of apps from other apps, don't make it something in the apps' domain. Only allow Wayland to take the screenshots, but support that, make it easy, and you won't need to worry about either the security model or users complaining. I mean, this is the way other OSes do it...to the best of my knowledge (which is certainly not comprehensive) neither Windows nor macOS allow arbitrary apps to screenshot arbitrary portions of the screen; that's handled by the OS itself.
- derefr 6y ago
  I think that (the compositor doing the screenshotting) is already the way it works. But "screenshots" (i.e. fed to the user as files / on the pasteboard) are the exception, not the rule, of the use of this API. The normal, non-edge-case use of the relevant screen-capturing API is for screen-sharing ala Zoom, or for remote desktop using RDP et al. These are use-cases where one app wants to see what's going on in other apps — exactly the thing you wouldn't want a malicious app to be able to do, but also exactly the thing that you do want these apps to be able to do.