Trying wayland by default again

FYI the author of the merge request you link there (Vitaly Prosyak [AMD]) is mentioned in the Collabora blog post to be working with them. You can see that in the wayland-protocols WIP proposal and other merge requests linked in their blog post. I hope that Google funding colour management and HDR support on Wayland for ChromeOS in collaboration with AMD, Intel, and others is the push this needs to get it across the line.


When I saw that Wayland was going to be the default for Hirsute, I decided to try it on my Focal 20.04.1 system. Running on my trusty old Lenovo Thinkpad T420, I logged out and back on again with Wayland instead of the default session.

At first everything SEEMED normal but then I started noticing some annoying issues. For one thing, mouse movement was not smooth, it was “herky-jerky” across the screen.

Next, I use a little snap app called “Bucklespring” that makes my laptop sound like my desktop with its IBM Model-M keyboard. The sound kept cutting out… sometimes keystrokes would “click” other times they were silent. Same for the mouse clicks.

Switching through work spaces was also “herky-jerky” and not nearly as smooth and “flowing” as using X. I hope you guys actually get Wayland working at LEAST as well as X. In my experience, “new” isn’t always “better” and right now this is definitely the case with Wayland.

I haven’t even tried it on my desktop AMD system where I run Steam games…

1 Like

While I love this idea, there are certain minor details that might need to be addressed. Especially if Wayland is going to be default in the next LTS. For example I just noticed this morning that you don’t have the ability to use system window decoration with the telegram snap application while on Wayland, but I do in x session.

As explained in the previous replies, that works in Wayland natively for some time now.

In ubuntu we also support per-screen fractional scaling under X11 (with similar approach to your script) but has some limitations as well because of how Xorg works.

I added support for this while doing the work, then we decided not to expose it in the display UI, but maybe could be used as an a11y feature.

It may have some bugs now, but code has been done with this option in mind.

I believe this is being actively worked on with the input thread efforts (see ) and other optimisations for the Wayland implementation in mutter.

May need some gtk wayland protocol extension indeed

This is indeed part of the work needed to get better input management.
Also further improvements have been added in the next releases.

Next, I use a little snap app called “Bucklespring” that makes my laptop sound like my desktop with its IBM Model-M keyboard. The sound kept cutting out… sometimes keystrokes would “click” other times they were silent. Same for the mouse clicks.

I maintain that snap, and is cool but unfortunately not really wayland friendly, being the example how insecure can be X (it reads any keypress you do), clear the fact of being open source software you can trust it, but that may works also for other less free clients.

So, for something like it, probably something more integrated should be implemented, or optionally a gnome-shell-extension would do the job.

In general I want to make sure that, as mentioned, this change won’t be affecting who wants still continue to work on X11, that backend is already 2nd-world citizen upstream because all the efforts have to be put in the wayland backend, but we’ve already million of users on it, so we can’t just abandon it.
I appreciate letting us know about the issues and the real professional scenarios it still addresses (a part the more obvious ones), though.
So, thanks @KristijanZic for your detailed inputs.

However, wayland is the way to go now, and even if it may cause some headaches, we’ve to pass through them if we want to be part of this change, not just as spectators.

Ubuntu can be a driver to the change, and bringing our interest and users there can help all to get a better final result.

Another aspect that is quite important in the conversation, is the wayland instability which can be true, but even if the crashes might be as many as in X11, indeed their result can be way more dangerous as they imply loosing the whole session, and may be a big problem in some working environments.

In this concern, there’s a protocol that has been drafted, and we’d like to work on it to help get that happening.


Last year, while looking for existing bug reports on this issue, I found these pages:

It seems there was at least an attempt to solve the problem.

1 Like

Downscaling is bug 1724037.

Input threads and lack thereof, is bug 1690719.

Middle clicking not working anymore for vertical maximization is bug 1698083.

Please use the existing bugs for those discussions.


Please keep in mind that I am on Ubuntu 20.04 LTS, and what I am seeing when using Wayland are to that release. I will set up a test environment in KVM and see how it works there. That being said, I did notice not drop shadows for Firefox Snap version. I will double check in test environment and if it still persists, I will submit a bug.

Anyone got screen sharing working in Firefox under Wayland yet on Groovy or Hirsute? Please share how in that case!


I don’t know if it’s meant to work. Certainly legacy screenshot/sharing apps for X11 do not work in Wayland, because Wayland is designed to be more secure than X11 and not give any programs the ability to read the screen. Only the shell itself can read the whole screen, but the shell might provide that ability to apps in future?..

If it is meant to work then:

  1. Make sure you’ve enabled native Wayland support for Firefox by adding this line to /etc/environment
    Without that you’re using Firefox on X11 connected to Xwayland.
  2. Reboot.
  3. If it still doesn’t work then please search for relevant bugs at (because there seem to be more relevant ones there than in Launchpad).
1 Like

FYI, Wayland is now default in hirsute.


Right, I’ve heard people on other distros got it working!

So the webrtc component of Firefox should be compiled with rtc_use_pipewire, it has Pipewire support. I’m not sure if this is done…

I am running with MOZ_ENABLE_WAYLAND=1.

But I don’t get it to work on Hirsute. I guess I don’t have all the Pipewire and portal stuff installed and/or running correctly…

Yeah Pipewire would be one way to make screen sharing work in Gnome Shell Wayland sessions (probably not in other Wayland compositors though). But before that can work we will need to update the libmutter-7-0 package to enable Pipewire support.

1 Like

I get the impression that Firefox uses libpipewire 0.2, from

Saw somewhere that OpenSuse has a 0.3 patch? Says re. Fedora: “The PipeWire support in Firefox unfortunately needs to be enabled during build by handmade changes, which is most likely not happening in other distributions, but from what I now there is an ongoing effort to make this configurable with a build option.”

1 Like

Sooo… We had few problems, I’ve addressed them all and now both screen sharing (note, in Firefox only but it works both when using native wayland backend - using MOZ_ENABLE_WAYLAND and using X11 in Xwayland) and remote desktop are working:

You will have to wait for the packages (libvncserver and xdg-desktop-portal) that are currently proposed or debian unstable to hit hirsute.

Chromium / Chrome are a bit more problematic right now (even after setting the chrome://flags/#enable-webrtc-pipewire-capturer parameter).


Do you have to actually have the remote desktop access running and listening on a network port for this to work, or how are these things interconnected?

With the exception of Mir, I think all commonly used Wayland compositors now integrate with PipeWire for screensharing. Both KWin and wlroots have implementations using PipeWire, and that covers pretty much everything I’m aware of.


Alright, now I’ve learned more, you don’t need any of the gnome-remote-desktop stuff for browser screen sharing, just clarifying! :slight_smile:

The important update seems to be the rebuild of Mutter with pipewire support. I’ve put the package in my PPA since every new package in Hirsute is stuck in libc 2.33 proposed-hell…