13 ms·

Wayland fixes a number of long standing issues with X, including: * No screen tearing. * Better hidpi support including different scale factors on different m

by nitsky 6y ago

Wayland fixes a number of long standing issues with X, including: * No screen tearing. * Better hidpi support including different scale factors on different monitors. * Improved security, because clients do not have access to all state on the server and servers do not run as root. Separately, I like how with Wayland the compositor is also the server, so from a TTY you can enter a desktop environment by running a single executable with a single configuration file.

jude- 6y ago
What happens to your graphical programs when your compositor crashes? At least with X11, if your window manager crashes, your programs keep running (you'd just fire up the WM again).
- colingw 6y ago
  Sway (the window manager) _is_ the compositor. There is no need for a separate program like compiz or picom.
  - sprash 6y ago
    Which is a mistake. On X11 the server, window manager and compositor are three separate programs. Both window manager and compositor can individually crash, started, stopped and replaced at runtime without any of the other running X11 client instances affected.
    - ubercow13 6y ago
      On the other hand on X11, Xorg cannot crash without the X11 client instances being affected - a much larger chunk of code. It's only because Xorg is older that that doesn't happen much.
      - sprash 6y ago
        A chunk of code that is running in production for more than 30 years and should be considered battle tested. In my experience Wayland compositors crash much more often than X11 despite the supposed reduced complexity. The last time X11 server crashed on me was in 2004 if I remember correctly.
        ubercow13 6y ago
        Exactly, that reliability of Xorg is a function of its age and doesn't imply anything about the correct design of a Wayland compositor. What's the chance those Wayland crashes were in the window management code rather than the rendering, protocol, clipboard, and drag/drop handling code? dwm is 2000 SLOC to Xorg's 1 million or so. I don't think splitting out the WM code would have gained much.
        sprash 6y ago
        You underestimate the inherent complexity of Wayland. As exercise I recommend to implement a "Hello World" native Wayland client. Watch and see the complexity explode when you simply want to add the functionality to take screenshots to that client.
        cycloptic 6y ago
        I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.
        sprash 6y ago
        I'm specifically not talking about toolkits. I'm talking about a "simple" native Wayland client. Try to write one and witness utter insanity.
        cycloptic 6y ago
  - jude- 6y ago
    Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthogonal design concerns (window management vs rendering). Sway is like putting X11, the window manager, the global hotkey daemon, screenshot grabber, and so on, all into the same address space. What could possibly go wrong? /s Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?
    - sprash 6y ago
      > I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point. The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand. 1.: https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/
      - cycloptic 6y ago
        The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
        jude- 6y ago
        Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.
- MayeulC 6y ago
  Well, the same as when X11 crashes, which happens... Apps lose their connection to X11 and kill themselves promptly, usually.
yes_but_no 6y ago
Also better gesture support for touchpads
- hawski 6y ago
  How?
  - kaba0 6y ago
    Wayland uses libinput by default, which is really great. Though it can be used with X as well, but it may not be as stable
gens 6y ago
Screen tearing under X11 is more or less not a problem anymore. HIDPI, yes, but only for multiple monitors (maybe even just programs that don't support it properly ?). Security... eh, yes and no (Xorg can be ran as a normal user). The actual good thing about Wayland is that it simplifies things. While the bad thing is that it needs some kind of extensions for even the basic things a desktop needs, and that (AFAIK) freeGNOMEdesktop is in charge now.
- pengaru 6y ago
  > Screen tearing under X11 is more or less not a problem anymore. For GLX/DRI clients where there's an actual concept of swapping buffers w/vsync, sure, but for classical X clients this is not true. X got extensions for double buffering at one point, but practically nobody uses them. There is no concept of a "completed frame ready for presentation" in core X, there's no way to really fix this without ceasing to be X (hello, Wayland). X compositors literally just drain event queues of X requests and throw shit on-screen when the event loop gets around to it. If that presents a partially updated window, so be it. GTK+/GNOME folks added "frame clocks" to try work around it, but not everything is a modern-ish GTK+ app, nor do all compositors implement it. If there's anything Wayland fixes that really required such an upheaval to fix, it's flicker/tear-free compositing.
  - gens 6y ago
    Well, it seems to work fine (xorg.conf tearfree option, that is). AFAIK wayland compositing also has the problem that clients don't know when they should be done with rendering, as in when the flip is going to happen. I don't know much about how it (wayland, DRI) actually works (as in, can the "client" just render where the compositor told DRI it should without involving the compositor, or does it have to tell the compositor when it rendered). GNOME3 had(has?) many a timing problems.
    - pengaru 6y ago
      If Wayland is throwing partially constructed buffers on-screen, it's the client's fault for submitting them unfinished. In X, there isn't really a concept of what a completion boundary is. The client asks stuff to be drawn, the display server gets around to it when it gets around to it, and makes the changes visible willy-nilly, eventually becoming consistent with the client state. If you look at the source for xcompmgr, the event loop is pretty simple and clearly schedules repainting the root window with all newly received damage updates whenever its X socket is drained of new events [0]. This is a pretty arbitrary boundary to perform redrawing on; process scheduling, socket buffer sizes/limits, it's not well controlled at all. The way this is done it will make visible whatever damage events managed to get into this timeslice. If that results in only part of a window being updated, with the rest of the damage part of that "frame" arriving in the next timeslice, POOF, there's a tear. [0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/master/xcompmgr.c#L2379 https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/mast...
stevepike 6y ago
Can you explain the screen tearing thing? I'm running kwin on X and I don't notice any screen tearing (including doing things like moving windows around rapidly with the "wobbly windows" effect on).
- MayeulC 6y ago
  That is because you use a compositor, which composites the screen in a separate buffer before presenting it. But in my experience, there were some edge cases where something like videos would tear.

by nitsky 6y ago

jude- 6y ago

What happens to your graphical programs when your compositor crashes? At least with X11, if your window manager crashes, your programs keep running (you'd just fire up the WM again).

colingw 6y ago
Sway (the window manager) _is_ the compositor. There is no need for a separate program like compiz or picom.
- sprash 6y ago
  Which is a mistake. On X11 the server, window manager and compositor are three separate programs. Both window manager and compositor can individually crash, started, stopped and replaced at runtime without any of the other running X11 client instances affected.
  - ubercow13 6y ago
    On the other hand on X11, Xorg cannot crash without the X11 client instances being affected - a much larger chunk of code. It's only because Xorg is older that that doesn't happen much.
    - sprash 6y ago
      A chunk of code that is running in production for more than 30 years and should be considered battle tested. In my experience Wayland compositors crash much more often than X11 despite the supposed reduced complexity. The last time X11 server crashed on me was in 2004 if I remember correctly.
      - ubercow13 6y ago
        Exactly, that reliability of Xorg is a function of its age and doesn't imply anything about the correct design of a Wayland compositor. What's the chance those Wayland crashes were in the window management code rather than the rendering, protocol, clipboard, and drag/drop handling code? dwm is 2000 SLOC to Xorg's 1 million or so. I don't think splitting out the WM code would have gained much.
        sprash 6y ago
        You underestimate the inherent complexity of Wayland. As exercise I recommend to implement a "Hello World" native Wayland client. Watch and see the complexity explode when you simply want to add the functionality to take screenshots to that client.
        cycloptic 6y ago
        I'm not sure what kind of "Hello World" clients you're comparing, but if you check the Wayland backends in Gtk/Qt, you will actually find them to be smaller than the respective X11/XCB backends there, for various reasons.
        sprash 6y ago
        I'm specifically not talking about toolkits. I'm talking about a "simple" native Wayland client. Try to write one and witness utter insanity.
        cycloptic 6y ago
- jude- 6y ago
  Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthogonal design concerns (window management vs rendering). Sway is like putting X11, the window manager, the global hotkey daemon, screenshot grabber, and so on, all into the same address space. What could possibly go wrong? /s Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?
  - sprash 6y ago
    > I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point. The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand. 1.: https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/
    - cycloptic 6y ago
      The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
      - jude- 6y ago
        Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.
MayeulC 6y ago
Well, the same as when X11 crashes, which happens... Apps lose their connection to X11 and kill themselves promptly, usually.

yes_but_no 6y ago

Also better gesture support for touchpads

hawski 6y ago
How?
- kaba0 6y ago
  Wayland uses libinput by default, which is really great. Though it can be used with X as well, but it may not be as stable

gens 6y ago

Screen tearing under X11 is more or less not a problem anymore. HIDPI, yes, but only for multiple monitors (maybe even just programs that don't support it properly ?). Security... eh, yes and no (Xorg can be ran as a normal user). The actual good thing about Wayland is that it simplifies things. While the bad thing is that it needs some kind of extensions for even the basic things a desktop needs, and that (AFAIK) freeGNOMEdesktop is in charge now.

pengaru 6y ago
> Screen tearing under X11 is more or less not a problem anymore. For GLX/DRI clients where there's an actual concept of swapping buffers w/vsync, sure, but for classical X clients this is not true. X got extensions for double buffering at one point, but practically nobody uses them. There is no concept of a "completed frame ready for presentation" in core X, there's no way to really fix this without ceasing to be X (hello, Wayland). X compositors literally just drain event queues of X requests and throw shit on-screen when the event loop gets around to it. If that presents a partially updated window, so be it. GTK+/GNOME folks added "frame clocks" to try work around it, but not everything is a modern-ish GTK+ app, nor do all compositors implement it. If there's anything Wayland fixes that really required such an upheaval to fix, it's flicker/tear-free compositing.
- gens 6y ago
  Well, it seems to work fine (xorg.conf tearfree option, that is). AFAIK wayland compositing also has the problem that clients don't know when they should be done with rendering, as in when the flip is going to happen. I don't know much about how it (wayland, DRI) actually works (as in, can the "client" just render where the compositor told DRI it should without involving the compositor, or does it have to tell the compositor when it rendered). GNOME3 had(has?) many a timing problems.
  - pengaru 6y ago
    If Wayland is throwing partially constructed buffers on-screen, it's the client's fault for submitting them unfinished. In X, there isn't really a concept of what a completion boundary is. The client asks stuff to be drawn, the display server gets around to it when it gets around to it, and makes the changes visible willy-nilly, eventually becoming consistent with the client state. If you look at the source for xcompmgr, the event loop is pretty simple and clearly schedules repainting the root window with all newly received damage updates whenever its X socket is drained of new events [0]. This is a pretty arbitrary boundary to perform redrawing on; process scheduling, socket buffer sizes/limits, it's not well controlled at all. The way this is done it will make visible whatever damage events managed to get into this timeslice. If that results in only part of a window being updated, with the rest of the damage part of that "frame" arriving in the next timeslice, POOF, there's a tear. [0] https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/master/xcompmgr.c#L2379 https://gitlab.freedesktop.org/xorg/app/xcompmgr/-/blob/mast...

stevepike 6y ago

Can you explain the screen tearing thing? I'm running kwin on X and I don't notice any screen tearing (including doing things like moving windows around rapidly with the "wobbly windows" effect on).

MayeulC 6y ago
That is because you use a compositor, which composites the screen in a separate buffer before presenting it. But in my experience, there were some edge cases where something like videos would tear.