This purpose of this page is to list the current missing or incomplete features in GNOME on Wayland to achieve a user experience on par with what is found on X11. But not all features listed here are equally important, there might even be some features listed which will not be implemented in Wayland eventually because they are not suitable.

This page is not meant to list known bugs or issues with existing features, nor how to debug Wayland issues, see How to debug Wayland problems for this.

It focuses primarily on GNOME because GNOME is the default desktop on Fedora Workstation, but features may need to be implemented at different levels not necessarily part of GNOME:

Pending

remote display

protocol, mutter

Completion: 90%

Remote display, using pipewire, has been included as an "experimental-feature" in GNOME-3.26

accessibility: mouse

mutter

Completion: 0%

Mouse accessibility features such as hover-to-click need to be reimplemented in the compositor. In contrast to keyboard accessibility,
these features are implemented outside the X server for X (in mousetweaks), so this is a bit simpler wrt to xwayland.

accessibility: device controller

mutter, at-spi-core

Completion: 0%

Orca has a feature called 'mouse review' which relies on the at-spi-registryd deviceeventcontroller interface to 'remote control' the
pointer. To provide this functionality under Wayland, mutter needs to provide a device controller interface and at-spi-registryd needs
to use it. After discussing this with Jonas, this should be a D-Bus interface, it doesn't need to be a Wayland protocol.

Device and Driver information

mutter, gnome-control-center

Completion: 0% (TBD)

We want to show the same kind of GPU information in the Details pane of gnome-control-center that we get from GL_RENDERER under X11; currently, it just says "Wayland" there. I'm not entirely sure why this isn't done, glGetString(GL_RENDERER) works just fine under EGL.

One thing we may want to do is show that result for both EGL and GLX contexts, since they may differ.

Hotplug USB devices

The DisplayLink USB2 devices work under X now when hotplugged as an extra screen. These should remain working under wayland.

The clutter merge and the multi-framebuffer work to support this have been merged.

Outputs on secondary GPUs

mutter

Completion: 50%

Laptops where the external outputs are only connected to a secondary GPU needs to be supported in some form. These work under X currently using
reverse prime.

The clutter merge and the multi-framebuffer work that will support this have been merged.

Remove X11 requirement in mutter

mutter

Completion: 50%

Quoting Owen in upstream bug 759538: Currently, mutter will start Xwayland at startup unconditionally because it still depends on "X11 backend to GTK+ for various things within Mutter and GNOME Shell, such as theme drawing and input methods. I think we'd need to eliminate the use of GTK+ for input methods, then have some no-backend mode to use GTK+ for theme drawing without actually opening a connection to a display server".

Nvidia driver support

mutter, Xwayland, nvidia drivers

Completion: 50%

This is obviously less important for Fedora, since we don't ship the Nvidia driver, but I am listing it here anyway, since it is important for many users. Nvidia recently released version 364 of its driver, which brings "support for Wayland and Mir". Concretely, this means that the EGLDevice, EGLOutput and EGLStreams APIs are supported. Mutter will need to grow support for these (parallel to cogls current gbm support)...

Lyude has bee nworking on eglstream support in Xwayland as well.

Clipboard manager

protocol, gtk+, mutter

Completion: 0%

Under X11, gnome-settings-daemon offers an api to store the contents of the clipboard when the selection owner exits, and continues to make the clipboard contents available.
Weston has a simple functionality, but without the optimization to only store the clipboard contents on exit.
Mutter does not currently offer this.

Restarting gnome-shell

Under X11, gnome-shell can be restarted at will without losing the current session (using AltF2 → "r"). Similarly, the user session under X11 can survive a crash in gnome-shell as the session manager will automatically restart it.

Under Wayland, being the Wayland compositor as well, gnome-shell cannot be restarted without restarting the entire user session. Using AltF2 → "r" states that "Restart is not available on Wayland".

As a result, if gnome-shell crashes under Wayland, the entire user session is terminated unexpectedly.

Complete

Color temperature control

protocol, mutter

Completion: 100%

night-light, a similar feature to Redshift, has been merged into GNOME 3.24 and works on Wayland.

Window size hints

The wayland shell protocols lack the equivalent of ICCCM's WM_NORMAL_HINTS.

The resize increment is particularly useful for terminal emulators, which have to resize with character cell granularity. Mutter will display this information when resizing an X window, so this works for xterm, but not for gnome-terminal. We've just removed resize increments from GTK+, I don't think this should be added to Wayland.

Size hints have been added to the forthcoming xdg-shell v6. But that doesn't include size increments or aspect ratio, just min/max size.

min/max size support will be merged soon.

on-screen keyboard

protocol, mutter

Completion: 100%

The on-screen keyboard in gnome-shell currently does not work under Wayland. That needs to be fixed as a starting point. Doing a better job on OSK requires moving away from a key event based protocol to something more like a text protocol, which is where this task overlaps with input methods.

Carlos has been working on this.

Optional surface IDs

protocol, gtk+, mutter

Completion: 100%

This will be useful for xdg-app portals, so the portal can place dialogs relative to application surfaces.
Jonas has a protocol proposal and an implementation.

All branches are ready to be merged.

Recording screencast

mutter, apps

Completion: 100%

Not sure what's missing here, unless you want to define a Wayland protocol for this. Recording screencasts using gnome-shell's D-Bus api works just fine
today in a Wayland session.

Live screencasts using third-party applications (such as video meeting or screen sharing from a web browser) are out of scope for this feature, and rather fall under "remote display".

Carlos has taken this over; he has mutter and gtk+ branches, and is now trying to finalize an agreed-on protocol. The branches have been merged now (including xwayland). Proper wayland protocol upstreaming is still pending

input methods

protocol, gtk+, mutter

Completion: 100%

The default input method setup in GTK+ is entirely client-side (display server send key events, the ibus module sends them over D-Bus to IBus...). This basically works under Wayland as it does under X, with the one exception that there is a problem with the placement of the candidate window. Rui is going to fix this for 3.19.90 [1]

accessibility: screen reader

Completion: 90%

Screen reading (orca) works more or less the same as under X: all the accessibility traffic goes over D-Bus (the a11y bus, to be precise).
One part that doesn't work is what orca calls 'mouse review', since it relies on the device event controller functionality of at-spi-registryd.

Other dnd features

gtk+, mutter

Completion: 100%

Need to complete support for

Drag icons (DONE)

Hotspots (DONE)

Reliable drag end determination (DONE)

Cancel animation (DONE)

Protocol additions for drag end and cancel animation have been merged.

attached modal dialogs

applications

Completion: 95%

Note: Not sure if that should be seen as a bug or a feature. gtk+ rightfully sets "set_parent" in its wayland backend for transient windows, and it works in both gnome-shell and weston, but some apps don't use transient relationship and rely on the window manager to treat dialogs as transients for all windows of the same group. Those apps need to be fixed.

GTK+ now has reasonable support for this. Applications need to set transient parents on their dialogs and popups.

bell support

mutter, protocol, gtk+

Completion: 95%

X has XkbBell to create various beeps in connection to a window. Most of this could be done client-side, but the ability to reconfigure this to use a visual bell makes it
something that needs to be provided by the compositor.

Jonas wrote a quick protocol, that for now is private between GTK+ and mutter. This has been merged for 3.19.92.
Left to do: agree on proper Wayland protocol for this and make xwayland use it.

accessibility: visual bell

protocol, gtk+, mutter

Completion: 100%

X has bell functionality as part of its protocol.

Jonas has added Wayland protocol to do this, for now private between GTK+ and mutter.

Xfree86-VidModeExtension in Xwayland

protocol, Xwayland

Completion: 100%

Note: Some games check for this extension and would refuse to start without. There are patches contributed but these are incomplete and not satisfactory. Beside, this is the same a current XRandR support, i.e. read-only, Xwayland apps cannot control the output configuration.

Under X11, applications can have active grabs on either the pointer or the keyboard. Applications such as virtual machine viewers use this feature.

By design (and on purpose), Wayland doesn't allow clients to have an active grab so it's a bit complicated for Xwayland to translate these to the Wayland compositor.

A possibility would be to use a Wayland protocol to inform the compositor that a Wayland or Xwayland application requests an active grab. The compositor would then either allow or deny the grab, possibly inform/ask the user and provide visual feedback when a grab is active.

Both shortcuts-inhibitor and Xwayland-grab protocols are in wayland-protocols 1.9
Support for shortcuts-inhibitor protocol for Wayland native is in GNOME-3.26 (mutter, gnome-shell, gtk+)
Support for Xwayland grabs is in Xserver master, support in mutter has landed in GNOME-3.27.

accessibility: keyboard

clutter, mutter

Completion: 100%

Under X, key repeat and AccessX features (sticky keys, slow keys, bounce keys, toggle keys, etc) are implemented in the X server.
Under Wayland, GTK+ currently implements key repeat on the client-side. There is a branch which adds the AccessX features, but
implementing these client-side is not ideal, and leads to some regressions.

[otaylor] We SHOULD NOT implement this. It's a vehicle for a game to mess up the user's system. The conceptual equivalent in Wayland is for an app to ask for it's buffer to be scaled or modeset fullscreen - and that needs to be implemented in Mutter - but I don't see providing to Xwayland apps; anything running under X11 I think just has to live with the screen's current configuration.