Fedora Workstation Next Steps: Wayland and Graphics

Posted on by

So I realized I hadn’t posted a Wayland update in a while. So we are still making good progress on Wayland, but the old saying that the last 10% is 90% of the work is definitely true here. So there was a Wayland BOF at GUADEC this year which tried to create a TODO list for major items remaining before Wayland is ready to replace X.

  • Proper menu positioning. Most visible user issue currently for people testing Wayland
  • Relative pointer/confinement/locking. Important for games among other things.
  • Kinetic scroll in GTK+
  • More work needed to remove all X11 dependencies (so that desktop has no dependency on XWayland being available.
  • Minimize main thread stalls (could be texture uploads for example)
  • Tablet support. Includes gestures, on-screen keyboard and more.

A big thank you to Jonas Ådahl, Owen Taylor, Carlos Garnacho, Rui Matos, Marek Chalupa, Olivier Fourdan and more for their ongoing work on polishing
up the Wayland experience.

So as you can tell there is a still lot of details that needs working out when doing something as major as switching from one Display system to the other, but things are starting to looking really good now.

One new feature I am particularly excited about is what we call multi-DPI support ready for Wayland sessions in Fedora 23. What this means is that if you have a HiDPI laptop screen and a standard DPI external monitor you should be able to drag windows back and forth between the two screens and have them automatically rescale to work with the different DPIs. This is an example of an issue which was relatively straightforward to resolve under Wayland, but which would have been a lot of pain to get working under X.

We will not be defaulting to Wayland in Fedora Workstation 23 though, because as I have said in earlier blog posts about the subject, we will need to have a stable and feature complete Wayland in at least one release before we switch the default. We hope Fedora Workstation 23 will be that stable and feature complete release, which means Fedora Workstation 24 is the one where we can hope to make the default switchover.

Of course porting the desktop itself to Wayland is just part of the story. While we support running X applications using XWayland, to get full benefit from Wayland we need our applications to run on top of Wayland natively. So we spent effort on getting some major applications like LibreOffice and Firefox Wayland ready recently.

Caolan McNamara has been working hard on finishing up the GTK3 port of LibreOffice which is part of the bigger effort to bring LibreOffice nativly to Wayland. The GTK3 version of LibreOffice should be available in Fedora Workstation 23 (as non-default option) and all the necessary code will be included in LibreOffice 5 which will be released pretty soon. The GTK3 version should be default in F24, hopefully with complete Wayland support.

For Firefox Martin Stransky has been looking into ensuring Firefox runs on Wayland now that the basic GTK3 port is done. Martin just reported today that he got Firefox running natively under Wayland, although there are still a lot of glitches and issues he needs to figure out before it can be claimed to be ready for normal use.

Another major piece we are working on which is not directly Wayland related, but which has a Wayland component too is to try to move the state of Linux forward in the context of dealing with multiple OpenGL implementations, multi-GPU systems and the need to free our 3D stack from its close ties to GLX.

This work with is lead by Adam Jackson, but where also Dave Airlie is a major contributor, involves trying to decide and implement what is needed to have things like GL Dispatch, EGLstreams and EGL Device proposals used across the stack. Once this work is done the challenges around for instance using the NVidia binary driver on a linux system or using a discreet GPU like on Optimus laptops should be a thing of the past.

So the first step of this work is getting GL Dispatch implemented. GL Dispatch basically allows you to have multiple OpenGL implementations installed and then have your system pick the right one as needed. So for instance on a system with NVidia Optimus you can use Mesa with the integrated Intel graphics card, but NVidias binary OpenGL implementatioin with the discreet Optimus GPU. Currently that is a pain to do since you can only have one OpenGL implementation used. Bumblebee tries to hack around that requirement, but GL Dispatch will allow us to resolve this without having to ‘fight’ the assumptions of the system.

We plan to have easy to use support for both Optimus and Prime (the Nouveau equivalent of Optimus) in the desktop, allowing you to choose what GPU to use for your applications without needing to edit any text files or set environment variables.

The final step then is getting the EGL Device and EGLStreams proposal implemented so we can have something to run Wayland on top of. And while GL Dispatch are not directly related to those we do feel that having it in place should make the setup easier to handle as you don’t risk conflicts between the binary NVidia driver and the Mesa driver anymore at that point, which becomes even more crucial for Wayland since it runs on top of EGL.

20 thoughts on “Fedora Workstation Next Steps: Wayland and Graphics”

  1. Thank you for not pushing Wayland as the default in Fedora before it was ready. The new drive for stability is the reason why I was able to switch from Ubuntu to Fedora. Thank you.

  2. One detail that is extremely inconvenient from a user point of view is the X11/wayland clipboard interoperability. I’m running fedora 22, and as of yet that doesn’t seem to be fixed (or implemented), which means that a command line or quote (for example) on a web page, say from stack overflow, can’t be copied from the browser (chrome or chromium) to the terminal or from the terminal to an email message.

    Surprising how many times a day one wishes to do that. I understand that the wayland environment doesn’t have such a thing as a clipboard, so the implementation is in Gtk+, and wayland gtk+ and X11 gtk+ aren’t really the same thing at all.

    So it looks like you can solve the problem by either adding some kind of extension to Xwayland allowing access to the clipboard from outside the server, which seems feasible, and a callback to alert gtk+ wayland when new data is in the clipboard, or port every important application one is liable to run into to wayland.

    It appears that the choice has been hertofore to port everything to wayland. A good idea as far as it gooes, and it certainly isn’t either or, but that would also have to not just libre office, but wps, chromium (well on its way), emacs, blender, and more besides.

    In my experience, this problem is virtually the first thing one sees when starting to use wayland. It leaves the distinct impression that the environment is not quite put together yet. Wouldn’t it be a good idea to address it?

  3. One of the first things i noticed was that I couldn’t turn off the laptop touch pad. Can wayland do this yet?

  5. “We plan to have easy to use support for both Optimus and Prime (the Nouveau equivalent of Optimus) in the desktop, allowing you to choose what GPU to use for your applications without needing to edit any text files or set environment variables.”
    – Cool, though pretty useless without https://bugs.freedesktop.org/show_bug.cgi?id=69101 being fixed first (affects all OpenGL-based compositors).

  6. Let me express some more wishes here.

    1. Out to multiple GPUs at once. This is required on some Optimus-based laptops, because e.g. the Intel card drives the internal panel, but the HDMI output is connected to the Radeon card.

    2. GPU hotplug (at least in terms of outputs, but would be cool for rendering, too). Relevant on Sony laptops, because they have a Radeon GPU in the docking station. Also relevant for USB DisplayLink devices.

  7. The stalls on the main thread are sufficiently severe to make gnome-shell unusable for me. This is a recent regression though, I don’t remember earlier versions being this bad.

    Some kind of shell UI integration for Prime would be really good, I just wish efforts would go to getting reclocking working on Nouveau supported hardware rather than on the binary blob.

  9. If everyone lists their pet peeves, mine is that under X, I have gnome-shell crash almost daily. But under X, it’s no problem, because it just restarts and all of my applications keep on working. But with the current gnome-shell/wayland architecture, I understand that this will crash all of my applications too. We need to separate the UI and the actual compositor like Android does!

    • To me on Fedora 22 under X, X takes applications too with occasional crash most of the time with “Oh no! Something has gone wrong” message. I guess I am experiencing very bad driver crashes.

  10. With the multi-DPI support, what happens if you have a window straddling two monitors? Will different parts of the window be drawn at different DPIs? Or will it draw with the DPI of the monitor it is mostly on?

    • Testing in the current Fedora 23 alpha, it seems that a window straddled across screens with different DPIs is drawn with the monitor-it’s-mostly-on’s DPI setting, and the part that straddles to another screen appears either double-size or half-size.

      Once the window transitions over to being mostly on the other screen, it switches DPIs to the new monitor’s size.

      It would be nice if the compositor could scale the “wrong-DPI” portions to the appropriate on-screen size, as Mac OS X does.

  11. Thanks for pushing the Linux desktop forward like this. I’m super excited about the multi-DPI and GLdispatch stuff.

    When I tested the Wayland session in 3.16 with nouveau I noticed that the option to rotate the display was missing (for portrait mode). Will there be something like xrandr for Wayland in the future or how will this be handled?

  12. multi-DPI support is definitely not ready: the patches from Jonas haven’t been completed or reviewed, and it’s highly unlikely they will be, before the GNOME 3.18 release. I discussed the topic briefly at GUADEC, but there’s a lot of work to do — especially because the whole stack from the Shell down to Cogl is affected.

    Fedora 24 is a much more realistic target for that.

  13. awesome post and really exciting things you’re working on from the end user perspective. Kudos for doing those and approaching the problems in a sensible manner, not forcing things too much and working from the bottoms up.
    With those features made most of the main hurdles I had to overcome (which was not that difficult – Optimus and tearing were among the most annoying ones) when switching to Linux could be a thing of a past. Which will really ease the things for the new users. The only hurdle left, but completely outside the scope of this post, is finding/getting apps (hunting for repos, looking for a build for your distro etc is a pain).
    Fedora has been amazing for me so far . I’ve tried switching to Linux a couple of times in the past unsuccessfully, but Fedora 21 really hit the spot for me. First of all it runs great and with simple gnome tweaks/themes looks great (nice out of the box). Then also I’ve been lucky that some of the proprietary apps I use for work got a Linux version around that time (3d stuff – for example Modo) and some of the open source programs got to the point they’ve started to be a viable alternative for me (Krita for example).
    With all the advancements on the Linux front and the apps choice getting better I’m really looking forward to see what will happen in the next 2-3 years.
    Thx for working on those advancements!

Comments are closed.