Why Wayland anyway ?

30 Comments

The Fedora Workstation working group decided this week that we’re not quite there yet for making the Wayland session the default in Fedora 24.

That is a bit of a disappointment for me, since we have worked very hard this cycle to close the gaps;  you can see the progress we’ve made here: primary selection, kinetic scrolling, drag-and-drop,  startup notification, pointer confinement have all landed this cycle. Not to mention countless smaller bug fixes and robustness improvements. But gaps are gaps, so we will take one more cycle to address them.

winter

In any case, the Wayland session in Fedora 24 will be the best Wayland session we’ve ever had, and I really encourage everybody to try it out when F24 released.

Chances are that you won’t be able to tell the difference between the X and Wayland sessions. That is of course intentional – we’ve put a lot of effort into making sure that things work as well or better than before. But it is also a bit of a dilemma for advertising the Wayland work.

Why do it if everything is the same in the end ?

Isolation

One reason is that Wayland is designed from the ground up to isolate clients from each other.  There is no shared coordinate space. Wayland clients cannot snoop on each others input or inject fake input events. They can’t draw on each others windows or cover up windows with fake replicas.

All of these things and many other exploits are possible for malicious X clients, because the X protocol wasn’t designed for untrusted clients.

This makes Wayland a much better choice of display protocol when sandboxing untrusted applications, like xdg-app does.

Baggage

Another reason for using Wayland is that the Wayland protocol is a much better fit for a modern, compositing-based display system.

The X protocol contains many pieces that are simply no longer relevant today, like core fonts or core rendering. Modern toolkits and applications don’t use most of the protocol, but the obsolete parts have to stay if you want to claim to implement the X11 protocol.

Some problematic parts of the X protocol, such as grabs, are simply not present under Wayland.

Extensibility

A third reason for Wayland is that it will be a good basis to enable features that are hard to support under X, such as input transformation or smooth transitions between composited desktop and fullscreen clients.

Currently, we are still playing catch-up with the features of the traditional X session, so we haven’t really done much work on such new features yet. But as a small example,  we’ve already seen that it was relatively easy to add touchpad gesture support to Wayland, while X doesn’t have them yet.

There are more reasons for Wayland beyond these three, and you can read more about them e.g.  here or here.

Try it

Again, if you haven’t tried Wayland yet, the F24 release will be a great time to do so. Simply select the Wayland session (currently just called GNOME) in the session chooser on the login screen:

login

30 thoughts on “Why Wayland anyway ?”

  1. For decades I have been supporting normal desktop users and Copy and Paste are a basic requirement for any standard desktop environment.

    At this stage of its development it seems crazy that such a fundamental requirement is not yet working.

    1. Copy/paste worked for a long time. This cycle has primary selection (“middle click paste”). I do agree middle click paste is very important (for me it is critical; I use it that often).

  3. Just out of curiosity, does the GNOME project set or recommend a default session? If so, will the Wayland backend be the GNOME upstream default for 3.20?

    1. I might have gotten some details wrong, so YMMV.

      The (Wayland) standard for primary selection (basically same as middle click paste) arrived quite late. Technically it works a bit different than before. Instead of “copying” when you select in the new standard it sort of does a copy/paste when you middle click (AFAIK). This standard is implemented within GTK+. Not exactly sure how it behaves in combination with other toolkits, GTK+2.x as well as applications using XWayland. There’s a standard now, so I assume anything which doesn’t work nicely is fixable.

  5. >There is no shared coordinate space. Wayland clients cannot snoop on each others input or inject fake input events. They can’t draw on each others windows or cover up windows with fake replicas.

    I’ve long wondered, how do you implement accessibility features and macros in that environment? What about software like OBS?

  6. It’s unfortunate but understandable that the goal to make it the default was not reached.
    I also think that Isolation is a very important aspect of Wayland but I do hope though that there will be some mechanism to temporarily/selectively relax this feature because the insecurity of X also made some convenient applications possible (e.g., docks, screen capture).
    I’m not sure whether this is a real problem/limitation of Wayland or if this is simply a case of doing X on Wayland that might need a more graceful/complete transition solution or whether it needs to be done by Wayland-aware applications and tackled by a new approach?

  7. I have used F24 with Wayland recently and it works pretty much perfectly for my use. Thanks for the great work!

    Still, there is one problem that disturbs me a little. The mouse cursor gets slow and sometimes stalls under heavy CPU or I/O usage. For example Activities -> Show Application button makes the mouse cursor stall for a while.
    I think I have seen a bug report in Bugzilla so it should be a known problem.

    [WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.

  8. I hope we can get per-display hidpi too… This is sorely needed.

    2. I’ve seen at least one developer explain that Wayland makes per display hidpi yes/no possible. While in X11 it is very cumbersome (theoretically can be done but then you cannot drag windows from one screen to another anymore; so practically it is a no).

      It would be nice to show off the new abilities Wayland brings!

  9. The developer team at Fedora have done an amazing job in finishing so many features in such a very short amount of time. I can’t believe they got even half of those features in. Especially, the relative/locking pointer confinement functionality.

    Although it can be discouraging for the developers to see Wayland not set as default, I do think the Fedora leadership made the right call. The remaining lack of features are just too many to offer a smooth transition. It would be bad publicity if Fedora goes back to its lack-of-polish days.

  12. Would be good to have Redshift working on Wayland, for people that work many hours in front of screens it’s essential.

    1. Not a Wayland developer, but I guess those applications would probably be implemented as shell plugins, since the Wayland shell now has the job of putting all Windows in place

  13. I’m running GNOME 3.19.x with Wayland on Ubuntu GNOME 16.04 and am very happy with it so far. Thanks for the awesome work and keep going. Next cycle just means more time to add even more awesomeness.

  14. Automatic multiseat may be broken (I don’t have a plugable) but multiseat is alive and well in F23, loginctl allows for multiseat

    loginctl status seat0
    loginctl attach seat2

    don’t attach any shared device i.e HDDs and printers

  15. Is this ‘the best we ever had’ an American Style of communication? You would have done something wrong if the new version is _not_ the best you ever had 😉

  16. I seem to remember that one of the original ideas behind Wayland was to write a smaller and faster version of X (i.e. the Baggage referred to here). To what extend has that been possible to achieve? If Wayland becomes fully feature-complete with regards to X, will that even be possible?

    1. Redshift seems to just adjust the gamma value. This is somewhat similar to what gnome-color-manager does. Not sure if gnome-color-manager works at the moment, but obviously it should.

      Possibility Redshift would need to do things a bit differently, but don’t see why not.

  19. I am really curious if there’s any progress on fractional UI scaling (such as 1.5x)? I’m really looking forward to this feature as modern laptops are shipped with higher resolution screens. GNOME already provides excellent 2x scaling mechanism. If wayland could down-scale that to, say, 1.5x, that would be awesome.

  20. I will move completely on Wayland when I’ll be able to share my screen(preferably primary display) via Google Hangouts (it’s a work thing). I don’t know if this is more of a Wayland or Hangouts thing….

    1. In brief: Currently you better stick with X11 if you need screen sharing.

      GNOME will add something for screen sharing as well as remoting. At the moment there’s nothing (AFAIK). The plans are at:
      https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/
      https://wiki.gnome.org/Initiatives/Wayland/Remoting

      Once there’s something (might or might not be like written above), then Hangouts still would need to support that method. That might take some time again.

      Wayland leaves this to the compositor AFAIK, so this might differ across KDE, GNOME and Weston based compositors. Ideally this should be standardized.

  21. Mir is not for me since it uses unity and I prefer lightweight desktops. I don´t like gnome for the same reason. i prefer Enlightenment, Mate or Lxqt because they are leightweight. i have hopes for Wayland to make everything more lightweight. If I didn´t like lightweight I could just as well use OSx or Windows 10. I want Linux to rock and when everything you do takes a lot of time I think this time is wasted from my time.

Comments are closed.