A Wayland status update

26 Comments

Peter argues that the question “Is Wayland ready yet?” is not the best question to ask.  Then maybe this is a better question:

Is GNOME on Wayland ready yet ?

It has been our goal for a while to get to a point where the Wayland port can be declared complete and ready to be enabled by default. We’ve come a long way since we started the porting effort in September 2013. In fact, we feel that we’re close enough that we can  aim for Wayland by default in Fedora 24.

But the last mile is always the longest, and there’s still a few steps to take before we’re there.  With this weeks releases of Wayland 1.9.91 and the GNOME 3.19.4 releases, we’ve taken a couple of the steps:

  • A lot of work has gone into fixing the positioning of dialogs, menus and other popups in applications. When it was first introduced, the GTK+ Wayland backend was using heuristics based on window type hints for this; now we are more strict about it: just setting a transient parent should be enough to ensure proper placement. We also try to handle dialogs without transient parent as good as we can.
  • Kinetic scrolling now works as well under Wayland as under X11 – or even better (at least as far as the protocol is involved; Wayland has explicit support for this while we are relying on driver-specific heuristics under X). The relevant Wayland protocol additions needed  for this are the axis stop events.
  • Drag-and-Drop under Wayland is now comparable to X11. This is the culmination of multiple efforts:  The Wayland protocol gained some necessary dnd events and supports actions now.  On the GTK+ side, we’ve moved drag icon creation and input handling to the GDK backends, where it can be done in a backend-specific manner.

Whats next ?

  • We should see initial support for Wacom  tablets in Wayland 1.10.
  • A replacement for the X11 primary selection (“middle click paste”) is also in the works; I hope we can reach agreement on the protocol soon.
  • Inside GTK+, menu positioning is being reworked in a similar way to DND: Pushing it down to GDK, where it can be implemented in a backend-specific manner. This is being driven by the team working on the Mir backend, but it will benefit Wayland just as well.

And here is a sneak preview of Wayland remoting that Jonas has been working on for a while:

26 thoughts on “A Wayland status update”

  1. Just a question: I tried gnome on wayland and it quite worked; but an extension that I maintain didn’t.

    With gnome on X, I only need to run gnome-shell –replace from a console and I can see all the error messages produced by a failing extension; but with gnome on wayland I don’t know how to do it. Can you help me?

    1. With Wayland, gnome-shell is the compositor, and all clients are directly connected to it (unlike X, where clients are directly connected to the display server, and the shell is off to the side). While it is in principle possible to preserve client connections while restarting the compositor (doing similar tricks to what systemctl daemon-reexec does), it is far from trivial, and nobody has looked seriously at implementing it so far.

      1. To me, this is still the biggest blocker, since gnome-shell has a lot of non-trivial code, including a javascript JIT and all, and it crashes multiple times a week on X. Before declaring Wayland support to be stable, we need a model where it can abort/segfault/etc without taking down the user applications. Either by keeping the sockets around, or by having a model where GTK+ can reconnect after a failure. A bit like we can reconnect to PulseAudio. That means separating the session state from the compositor connection…

        1. I think you’re right Olivier – there’s some really bad PR waiting to happen here for Wayland if Gnome ships Wayland enabled Gnome shell and it’s crashy, people will be losing work and walking away from Gnome.

        2. “[GNOME Shell] crashes multiple times a week on X” — Do you have a bug report with a stack trace?

          I haven’t seen a GNOME Shell crash in a couple of years.

          1. Here are some for you, just from Fedora 23!

            https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=gnome-shell&product=Fedora&query_format=advanced&short_desc=abrt&short_desc_type=allwordssubstr&version=23

            To be fair, it has improved a lot in the recent years, but but gnome-shell/clutter/mutter/gjs are is not at a point where it can be the “can not crash” part of the system. Also, this doesn’t count the times when I have to do “alt-f2 r” because it hasn’t crashed, but it got into an invalid state and misbehaves.

          3. The same. I think that the main culprit for crashing GS sessions past 3.16 release are extensions.

          4. Unfortunately, a quick look at e.g. the list of Fedora gnome-shell bugs will show you it still happens for many users, and it’s not always easy to debug:
            https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&classification=Fedora&component=gnome-shell&list_id=4514805&product=Fedora&query_format=advanced

            Not a big deal if the consequence is only some screen flickering, but much more serious if the whole session goes down.

          5. I have gnome-shell crash once in a while and yes, bugs are filed.
            On X, at least there’s just a pause while gnome-shell restarts, but on Wayland, it sounds like the entire session will be lost.

            On a related note, will gnome-shell still have the option to do a “reload”? (Alt-F2, r) This is very useful when it starts acting a bit funny or when modifying extensions.

    2. On top of what Matthias said: on most distros these days the output of gnome-shell is in the journal.

      journalctl –user -b will give you all the output of the session, just for look for gnome-shell in there and you’ll see any error or debug log
      (-b means current boot, -b-1 is the boot before the current one, etc.)

  2. Don’t forget about pointer confinement and locking. Without it you can’t “rek some n00bs” in Counter Strike on Wayland. 😉

  3. There is this for me on Fedora 23, it happens on every boot, and it seems that gdm falls back to plain xserver:

    http://paste.fedoraproject.org/313837/53485561/raw/

    I think it is related to a /etc/X11/xorg.conf.d snippet i have that disables a security extension in xserver.

    It works fine with regular xserver though

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

  5. You had me at “sneak preview of Wayland remoting” 🙂 a smarter damage-based remote desktop functionality built into GNOME by default is one of the most interesting opportunities this new display stack brings IMHO. Please do keep us updated on this front!

    I presume this test was done on a local network, how will it fare over the web, on fairly slow consumer broadband connections? GNOME’s current built-in X11-based VNC server, used in conjunction with clients such as Vinagre or Remmina, is extremely slow in that regard.

  6. With SDL 2.0.4 using Wayland by default, relative/locking pointer confinement becomes really important. A discussion should happen whether it would be ok to potentially break games for the entire Fedora 24 lifecycle.

    In my opinion, if Fedora wants to be a true competitor to Ubuntu and grab marketshare, then it should play the conservative card. Wait until Fedora 25 and get an extremely polished and mature release for all the major use cases.

  7. I am glad that we have VNC, but how about RDP and SPICE? I thought VNC is the old tech, and the latter two are the current trend?

  9. I tried using Wayland in Fedora 23, but I switched back to X because environment variables – especially $PATH – weren’t getting set up at login:
    https://bugzilla.gnome.org/show_bug.cgi?id=736660

    I know this is probably quite separate to most of the work on getting Wayland ready, but it would be annoying if Fedora 24 comes out with no reasonable way to configure environment variables for the user’s session.

    1. Existing vnc servers like vino are scraping screen contents from an X server, so they won’t work under Wayland.
      Jonas is working on a remoting daemon which gets frames passed from gnome-shell via a pinos pipeline.

  12. I’ve tried this under both fedora 23 and sonar. This mostly works, however there’s one thing that doesn’t quite work like it should. I hope this can be fixed by gnome 3.20, and that’s the display of desktop icons when enabled in gnome and other desktops. I think the non drawing of desktop icons is a known bug in gnome, due to the tight coupling of that part of gnome to xorg. I can’t remember the exact bug number but I have commented on it. Other than that, gnome works quite nicely under wayland, especially with AT tools such as orca, the on screen keyboard, etc.

Comments are closed.