From Fedora Project Wiki

 
(89 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Wayland Desktop features progress
Wayland Desktop features progress


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.
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.
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.
Line 14: Line 14:
  * gtk+: toolkit, handles client side decorations in Wayland
  * gtk+: toolkit, handles client side decorations in Wayland
  * apps: requires new applications
  * apps: requires new applications
= Pending =
== accessibility: device controller ==
* <code>mutter, at-spi-core, libei</code>
* Completion: 25%
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.
For QA and automated testing of the UI, there is [https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon gnome-ponytail-daemon] which proxies mutter/gnome-shell internal API to an dogtail-like API.
For more complex usages such as [https://symless.com/synergy Synergy] or [https://github.com/debauchee/barrier/wiki Barrier] work is under way with [https://gitlab.freedesktop.org/libinput/libei libEI] but that will require adding support in all the various relevant components (including [https://gitlab.freedesktop.org/whot/xserver/-/commits/wip/xwayland-eis Xwayland]).
== Restarting gnome-shell ==
* <code>mutter, gnome-shell</code>
* Completion: 0%
* See also: [[#Remove X11 requirement in mutter|Remove X11 requirement in mutter]]
* See also: https://bugzilla.redhat.com/show_bug.cgi?id=1367666
Under X11, gnome-shell can be restarted at will without losing the current session (using {{key press|Alt}} {{key press|F2}} → "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 {{key press|Alt}} {{key press|F2}} → "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 =
== Outputs on secondary GPUs ==
* <code>mutter</code>
* Completion: 100%
Multi GPU setups are supported since circa GNOME 3.28
== Hotplug USB devices ==
* <code>mutter</code>
* Completion: 100%
mutter 3.32 supports DisplayLink.
== Remove X11 requirement in mutter ==
* <code>mutter</code>
* Completion: 100%
X11 is not longer a requirement for GNOME Shell/mutter with Wayland. Xwayland is started on-demand by default since GNOME 40 when an X11 client needs it and work is under way to have Xwayland shutting down automatically when all X11 clients have left.
See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794
== Nvidia driver support ==
* <code>mutter, Xwayland, nvidia drivers</code>
* Completion: 100%
Hardware acceleration for GL and Vulkan is supported with Xwayland 21.1.2 and NVIDIA closed source driver series 470 using EGLStream.
== Device and Driver information ==
* <code>mutter, gnome-control-center</code>
* Completion: 100% (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.
== Clipboard manager ==
* <code>protocol, gtk+, mutter</code>
* Completion: 100%
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.
== accessibility: mouse ==
* <code>mutter</code>
* Completion: 100%
Mouse accessibility features such as hover-to-click are reimplemented in GNOME Shell/mutter.


== remote display ==
== remote display ==


* <code>protocol, mutter</code>
* <code>protocol, mutter</code>
* Completion: 20%
* Completion: 100%


Jonas is working on this. He is getting a 'pinos stream' out of gnome-shell.
Remote display, using pipewire.


== screencast ==
== Color temperature control ==


* <code>mutter, apps</code>
* <code>protocol, mutter</code>
* Completion: 100%
* Completion: 100%


Not sure whats 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.
night-light, a similar feature to Redshift, has been merged into GNOME 3.24 and works on Wayland.


== primary selection ==
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1285590
https://bugzilla.gnome.org/show_bug.cgi?id=741224


* <code>protocol, gtk+, mutter, Xwayland</code>
== graphics tablet support ==
* Completion: 20%
* See also: https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection


Lyude has a protocol suggestion and a working weston implementation.
* <code>libinput, protocol, libraries, gtk+, Xwayland</code>
* Completion: 100%


== dnd actions ==
Peter and Carlos are working on this.


* <code>protocol, gtk+, mutter, xwayland</code>
libinput support has been merged in libinput 1.2.
* Completion: 80%
 
Carlos has a protocol proposal, and working implementations.
See https://bugzilla.gnome.org/show_bug.cgi?id=755625


== kinetic scrolling ==
protocol support has been included in wayland-protocols 1.3.


* <code>protocol, gtk+, mutter</code>
Support in mutter and gtk+ have been merged
* Completion: 80%


Peter has a protocol proposal and a working implementation.
Support for tablets in Xwayland has landed in git master, with downstream backports in xserver-1.19.x branch
See https://bugzilla.gnome.org/show_bug.cgi?id=756729


== input methods ==
== Window size hints ==


* <code>protocol, gtk+, mutter</code>
* <code>protocol, gtk+, mutter</code>
* Completion: 0% (TBD)
* Completion: 100%
* See also: https://bugzilla.gnome.org/show_bug.cgi?id=764413
 
The wayland shell protocols lack the equivalent of ICCCM's [http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_normal_hints_property WM_NORMAL_HINTS].


{{admon/note|FIXME|I have no idea where we stand wrt input methods nor what is really meant by that}}
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.


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...). I was going to say that this basically works under Wayland as well, but then my system was locking up hard while I was interacting with the Kanji character chooser popup in the shell...
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.


Rui is supposed to work on this.
min/max size support will be merged soon.


== on-screen keyboard ==
== on-screen keyboard ==


* <code>protocol, mutter</code>
* <code>protocol, mutter</code>
* Completion: 0% (TBD)
* 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 ==
 
* <code>protocol, gtk+, mutter</code>
* 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 ==
 
* <code>mutter, apps</code>
* Completion: 100%


{{admon/note|FIXME|Not sure if we'd need a new app for that.}}
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.


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.
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".


Rui is supposed to work on this.
== dnd actions ==


== relative/locking pointer confinement ==
* <code>gtk+, mutter, xwayland</code>
* Completion: 100%


* <code>protocol, libraries</code>
Carlos has a protocol proposal, and working implementations.<BR>
* Completion: 80%
See https://bugzilla.gnome.org/show_bug.cgi?id=755625
* Note: Required for games
* See also: http://lists.freedesktop.org/archives/wayland-devel/2014-December/018653.html http://lists.freedesktop.org/archives/wayland-devel/2015-October/024726.html


Jonas has a protocol and implementations. Will land in Wayland 1.10.
Protocol additions for this have been merged.
See https://bugzilla.gnome.org/show_bug.cgi?id=744104
Mutter implementation of wl_data_offer v3 has been merged.
GTK+ support for this has been merged too.


== hi-dpi support ==
== dnd: root window drops ==  


* <code>protocol, gtk+, mutter</code>
* <code>protocol, gtk+, mutter</code>
* Completion: 100%
* Completion: 100%


{{admon/note|FIXME|Not sure what is meant by that, Wayland supports scaling of surfaces and mutter uses that afaik.}}
We need some way to transfer drop status information to the drag source.
 
Carlos is working on this [https://bugzilla.gnome.org/show_bug.cgi?id=762104 here].
 
== kinetic scrolling ==
 
* <code>gtk+, mutter</code>
* Completion: 100%
 
Peter has a protocol proposal and a working implementation.<BR>
See https://bugzilla.gnome.org/show_bug.cgi?id=756729
 
The Wayland protocol additions (pointer axis, etc) have landed.
The mutter implementation has landed.
The GTK+ support has landed upstream as well.


This should be complete, modulo bugs.


== attached modal dialogs ==
== relative/locking pointer confinement ==


* <code>gtk+, mutter, protocol</code>
* <code>protocol, libraries</code>
* Completion: 100%
* Completion: 100%
* 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.
* Note: Required for games
* See also: http://lists.freedesktop.org/archives/wayland-devel/2012-December/006637.html, http://lists.freedesktop.org/archives/wayland-devel/2015-November/025726.html
* See also:<BR>http://lists.freedesktop.org/archives/wayland-devel/2014-December/018653.html<BR>http://lists.freedesktop.org/archives/wayland-devel/2015-October/024726.html


I believe this was fixed in https://bugzilla.gnome.org/show_bug.cgi?id=745720 - No, I (ofourdan) think this is for simple dialogs/parent relationship whereas many apps in gtk+ simply use the dialog type without any specfific transient and mutter on X11 treats them as "transient for the group", placing them above all other toplevels of the same group, Wayland doesn't allow for this afaik.
Jonas has a protocol and implementations. Will land in Wayland 1.10.<BR>
See https://bugzilla.gnome.org/show_bug.cgi?id=744104


== tablet support ==
Merged in mutter 3.19.90


* <code>protocol, libraries, gtk+</code>
== hi-dpi support ==
* Completion: 0% (TBD)


Peter and Carlos have branches for this. At least the first part of it is supposed to land in Wayland 1.10.
* <code>protocol, gtk+, mutter</code>
* Completion: 100%


A bigger missing piece here is the control-center configuration support.
This should be complete, modulo bugs.
Some additional discussions around this topic in [https://bugs.freedesktop.org/show_bug.cgi?id=93315 upstream bug 93315]


== startup notification ==
== BLOCKER: startup notification ==


* <code>protocol, libraries, gtk+, mutter</code>
* <code>protocol, libraries, gtk+, mutter</code>
* Completion: 0% (TBD)
* Completion: 100% (TBD)
 
Carlos has branches with a minimal implementation that adds a new request to the private gtk-shell interface between gtk+ and mutter.
 
This work has been merged for 3.19.91


== clipboard proxy for xwayland ==
== touch proxy for xwayland ==


* <code>Xwayland</code>
* <code>protocol, gtk+, mutter, Xwayland</code>
* Completion: 50%
* Completion: 100%


Copy/paste does work, kinda.  There seem to be some cases where things don't manage to get from one side to the other; I (ajax) have hit cases where copying a URL from Firefox (an X11 app) into Evolution (wayland-native) doesn't do anything.  I suspect that's due to getting selection type negotiation wrong.  Pasting URLs from Firefox to gnome-terminal seems to work just fine, and I doubt g-t is doing any content type negotiation.
This should be complete, modulo bugs.


== touch proxy for xwayland ==
== BLOCKER: primary selection ==


* <code>protocol, gtk+, mutter, Xwayland</code>
* <code>protocol, gtk+, mutter, Xwayland</code>
* Completion: 100%
* Completion: 100%
* See also: https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection


{{admon/note|FIXME|Not sure what is meant by that, touch was added in Wayland and Xwayland by Carlos.}}
Lyude has a protocol suggestion and a working weston implementation.<BR>
See http://lists.freedesktop.org/archives/wayland-devel/2015-December/026084.html for the protocol.


This should be complete, modulo bugs.
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


== accessibility features ==
== input methods ==


* <code>protocol, gtk+, mutter</code>
* <code>protocol, gtk+, mutter</code>
* Completion: 0% (TBD)
* 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 [https://git.gnome.org/browse/gnome-shell/commit/?id=a13357c2a8206e08ff449fcdd92873ae652a5ebc]
 
== 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).
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.


Features that need to be reimplemented in the compositor (or gtk+) include:
== Other dnd features ==
* keyboard accessibility features (sticky keys, slow keys, bounce keys, sound keys, etc)
* visual bell - titlebar flashing won't work for csd. We should just flash the entire window in that case
* mouse accessibility features such as hover-to-click


== output rotation ==
* <code>gtk+, mutter</code>
* 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 ==
 
* <code>applications</code>
* 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.
* See also:<BR>http://lists.freedesktop.org/archives/wayland-devel/2012-December/006637.html,<BR>http://lists.freedesktop.org/archives/wayland-devel/2015-November/025726.html


* <code>mutter, apps</code>
I believe this was fixed in [https://bugzilla.gnome.org/show_bug.cgi?id=745720 upstream bug 745720]
* Completion: 0% (TBD)
* Note: Wayland protocol already supports output transformation, supported by Xwayland and weston can use it.
* See also: https://bugzilla.gnome.org/show_bug.cgi?id=745079


== XRandR control of Wayland outputs ==
For transients without parent, there is [https://bugzilla.gnome.org/show_bug.cgi?id=759161 upstream bug 759161]


* <code>protocol, Xwayland</code>
GTK+ now has reasonable support for this. Applications need to set transient parents on their dialogs and popups.
* Completion: 0% (TBD)
* Note: There is a "read-only" XRandR support in Xwayland, but it cannot send request back to the Wayland compositor so X11 applications have no control over the output configurations.
* See also: https://bugzilla.redhat.com/show_bug.cgi?id=1289714


[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.


== Device and Driver information ==
== bell support ==


* <code>mutter, gnome-control-center</code>
* <code>mutter, protocol, gtk+</code>
* Completion: 0% (TBD)
* Completion: 95%


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.
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.


One thing we may want to do is show that result for both EGL and GLX contexts, since they may differ.
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.


See https://bugzilla.gnome.org/show_bug.cgi?id=756914 for the discussion, and for why GL_RENDERER is not sufficient.
== accessibility: visual bell ==


== screensaver control ==
* <code>protocol, gtk+, mutter</code>
* Completion: 100%


* <code>protocol, mutter, Xwayland, apps</code>
X has bell functionality as part of its protocol.
* Completion: 0% (TBD)
* See also: https://bugs.freedesktop.org/show_bug.cgi?id=89440, http://lists.freedesktop.org/archives/wayland-devel/2015-November/025582.html


Not sure that anything is needed here. GNOME has been doing screensaver control entirely over D-Bus for many years.
Jonas has added Wayland protocol to do this, for now private between GTK+ and mutter.


== Xfree86-VidModeExtension in Xwayland ==
== Xfree86-VidModeExtension in Xwayland ==


* <code>protocol, Xwayland</code>
* <code>protocol, Xwayland</code>
* Completion: 0% (TBD)
* 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.
* 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.
* See also: https://bugs.freedesktop.org/show_bug.cgi?id=87806, http://lists.x.org/archives/xorg-devel/2015-September/047460.html, http://lists.x.org/archives/xorg-devel/2015-October/047559.html
* See also:<BR>https://bugs.freedesktop.org/show_bug.cgi?id=87806,<BR>http://lists.x.org/archives/xorg-devel/2015-September/047460.html,<BR>http://lists.x.org/archives/xorg-devel/2015-October/047559.html
* Series of patches sent for review: https://patchwork.freedesktop.org/series/3118/


== XVideo extension in Xwayland ==
== XVideo extension in Xwayland ==


* <code>Xwayland</code>
* <code>Xwayland</code>
* Completion: 0%
* Completion: 100%


Technically the extension is present, but no adaptors are exposed.  This should be wired up to the subsurface protocol if possible.
Technically the extension is present, but no adaptors are exposed.  This should be wired up to the subsurface protocol if possible.


== Optional surface IDs ==
Initial implementation by Olivier has landed.
 
== clipboard proxy for xwayland ==
 
* <code>Xwayland</code>
* Completion: 100%
 
This should be working, modulo bugs.
 
== Presenting windows ==


* <code>protocol, gtk+, mutter</code>
* <code>protocol, gtk+, mutter</code>
* Completion: 50%
* Completion: 90%


This will be useful for xdg-app portals, so the portal can place dialogs relative to application surfaces.
We need some way to implement gtk_window_present(), which applications reply on.
Jonas has a protocol proposal and an implementation.
 
Jonas added protocol to do this (for now private between gtk+ and mutter).


== Hotplug USB devices ==
== output rotation ==


* <code>mutter</code>
* <code>mutter</code>
* Completion: 0%
* Completion: 100%
* Note: Wayland protocol already supports output transformation, supported by Xwayland and weston can use it.
* See also: https://bugzilla.gnome.org/show_bug.cgi?id=745079
 
Support for hw rotation (as exposed by the graphics driver has landed upstream). Unfortunately, this support is less common in hw than one would think,
so a software fallback is still needed.
 
Support for hw independent rotation has been merged into mutter.
 
== Active grabs in Wayland and Xwayland ==
 
* <code>protocol, mutter, Xwayland</code>
* Completion: 100%
* https://bugs.freedesktop.org/show_bug.cgi?id=96547
* https://bugzilla.gnome.org/show_bug.cgi?id=752956
* https://bugzilla.redhat.com/show_bug.cgi?id=1285770
* https://bugs.freedesktop.org/show_bug.cgi?id=97333
* https://lists.freedesktop.org/archives/wayland-devel/2016-August/030863.html
 
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.
 
See also: https://bugzilla.gnome.org/show_bug.cgi?id=783342
 
== accessibility: keyboard ==
 
* <code>clutter, mutter</code>
* 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.
 
Slow keys, sticky keys, bounce keys, toggle keys and mouse keys support implemented, patches attached to bug https://bugzilla.gnome.org/show_bug.cgi?id=788564 pending reviews.
 
See: https://bugzilla.gnome.org/show_bug.cgi?id=788564
 
= Dropped =


The DisplayLink USB2 devices work under X now when hotplugged as an extra screen. These should remain working under wayland.
== XRandR control of Wayland outputs ==


== Outputs on secondary GPUs ==
* <code>protocol, Xwayland</code>
* Completion: 50% (TBD)
* Note: There is a "read-only" XRandR support in Xwayland, but it cannot send request back to the Wayland compositor so X11 applications have no control over the output configurations.
* See also: https://bugzilla.redhat.com/show_bug.cgi?id=1289714


* <code>mutter</code>
[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.
* Completion: 0%


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
For legacy games which relied on XRandR to adjust the screen size to their capacity, Xwayland emulates that using a viewport to scale the (fullscreen, unreparented) window so it appears as if the resolution was changed.
reverse prime.


== Window size hints ==
== screensaver control ==


* <code>protocol</code>
* <code>protocol, mutter, Xwayland, apps</code>
* Completion: 0%
* Completion: 0% (TBD)
* See also:<BR>https://bugs.freedesktop.org/show_bug.cgi?id=89440,<BR>http://lists.freedesktop.org/archives/wayland-devel/2015-November/025582.html


The wayland shell protocols lack the equivalent of ICCCM's [http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#wm_normal_hints_property 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.
Not sure that anything is needed here. GNOME has been doing screensaver control entirely over D-Bus for many years.


[[Category:Wayland]]
[[Category:Wayland]]
[[Category:Desktop]]
[[Category:Desktop]]

Latest revision as of 12:40, 9 September 2021

Wayland Desktop features progress

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:

* kernel: drm, evdev, etc.
* libraries: underlying libraries, e.g. libinput, libwayland, etc.
* protocol: requires a new Wayland protocol or amending an existing protocol
* Xwayland: X11 compatibility
* mutter: Wayland compositor
* gtk+: toolkit, handles client side decorations in Wayland
* apps: requires new applications


Pending

accessibility: device controller

  • mutter, at-spi-core, libei
  • Completion: 25%

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.

For QA and automated testing of the UI, there is gnome-ponytail-daemon which proxies mutter/gnome-shell internal API to an dogtail-like API.

For more complex usages such as Synergy or Barrier work is under way with libEI but that will require adding support in all the various relevant components (including Xwayland).

Restarting gnome-shell

Under X11, gnome-shell can be restarted at will without losing the current session (using Alt F2 → "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 Alt F2 → "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

Outputs on secondary GPUs

  • mutter
  • Completion: 100%

Multi GPU setups are supported since circa GNOME 3.28

Hotplug USB devices

  • mutter
  • Completion: 100%

mutter 3.32 supports DisplayLink.

Remove X11 requirement in mutter

  • mutter
  • Completion: 100%

X11 is not longer a requirement for GNOME Shell/mutter with Wayland. Xwayland is started on-demand by default since GNOME 40 when an X11 client needs it and work is under way to have Xwayland shutting down automatically when all X11 clients have left.

See https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1794

Nvidia driver support

  • mutter, Xwayland, nvidia drivers
  • Completion: 100%

Hardware acceleration for GL and Vulkan is supported with Xwayland 21.1.2 and NVIDIA closed source driver series 470 using EGLStream.

Device and Driver information

  • mutter, gnome-control-center
  • Completion: 100% (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.

Clipboard manager

  • protocol, gtk+, mutter
  • Completion: 100%

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.

accessibility: mouse

  • mutter
  • Completion: 100%

Mouse accessibility features such as hover-to-click are reimplemented in GNOME Shell/mutter.

remote display

  • protocol, mutter
  • Completion: 100%

Remote display, using pipewire.

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.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1285590 https://bugzilla.gnome.org/show_bug.cgi?id=741224

graphics tablet support

  • libinput, protocol, libraries, gtk+, Xwayland
  • Completion: 100%

Peter and Carlos are working on this.

libinput support has been merged in libinput 1.2.

protocol support has been included in wayland-protocols 1.3.

Support in mutter and gtk+ have been merged

Support for tablets in Xwayland has landed in git master, with downstream backports in xserver-1.19.x branch

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".

dnd actions

  • gtk+, mutter, xwayland
  • Completion: 100%

Carlos has a protocol proposal, and working implementations.
See https://bugzilla.gnome.org/show_bug.cgi?id=755625

Protocol additions for this have been merged. Mutter implementation of wl_data_offer v3 has been merged. GTK+ support for this has been merged too.

dnd: root window drops

  • protocol, gtk+, mutter
  • Completion: 100%

We need some way to transfer drop status information to the drag source.

Carlos is working on this here.

kinetic scrolling

  • gtk+, mutter
  • Completion: 100%

Peter has a protocol proposal and a working implementation.
See https://bugzilla.gnome.org/show_bug.cgi?id=756729

The Wayland protocol additions (pointer axis, etc) have landed. The mutter implementation has landed. The GTK+ support has landed upstream as well.


relative/locking pointer confinement

Jonas has a protocol and implementations. Will land in Wayland 1.10.
See https://bugzilla.gnome.org/show_bug.cgi?id=744104

Merged in mutter 3.19.90

hi-dpi support

  • protocol, gtk+, mutter
  • Completion: 100%

This should be complete, modulo bugs. Some additional discussions around this topic in upstream bug 93315

BLOCKER: startup notification

  • protocol, libraries, gtk+, mutter
  • Completion: 100% (TBD)

Carlos has branches with a minimal implementation that adds a new request to the private gtk-shell interface between gtk+ and mutter.

This work has been merged for 3.19.91

touch proxy for xwayland

  • protocol, gtk+, mutter, Xwayland
  • Completion: 100%

This should be complete, modulo bugs.

BLOCKER: primary selection

Lyude has a protocol suggestion and a working weston implementation.
See http://lists.freedesktop.org/archives/wayland-devel/2015-December/026084.html for the protocol.

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

I believe this was fixed in upstream bug 745720

For transients without parent, there is upstream bug 759161

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

XVideo extension in Xwayland

  • Xwayland
  • Completion: 100%

Technically the extension is present, but no adaptors are exposed. This should be wired up to the subsurface protocol if possible.

Initial implementation by Olivier has landed.

clipboard proxy for xwayland

  • Xwayland
  • Completion: 100%

This should be working, modulo bugs.

Presenting windows

  • protocol, gtk+, mutter
  • Completion: 90%

We need some way to implement gtk_window_present(), which applications reply on.

Jonas added protocol to do this (for now private between gtk+ and mutter).

output rotation

Support for hw rotation (as exposed by the graphics driver has landed upstream). Unfortunately, this support is less common in hw than one would think, so a software fallback is still needed.

Support for hw independent rotation has been merged into mutter.

Active grabs in Wayland and Xwayland

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.

See also: https://bugzilla.gnome.org/show_bug.cgi?id=783342

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.

Slow keys, sticky keys, bounce keys, toggle keys and mouse keys support implemented, patches attached to bug https://bugzilla.gnome.org/show_bug.cgi?id=788564 pending reviews.

See: https://bugzilla.gnome.org/show_bug.cgi?id=788564

Dropped

XRandR control of Wayland outputs

  • protocol, Xwayland
  • Completion: 50% (TBD)
  • Note: There is a "read-only" XRandR support in Xwayland, but it cannot send request back to the Wayland compositor so X11 applications have no control over the output configurations.
  • See also: https://bugzilla.redhat.com/show_bug.cgi?id=1289714

[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.

For legacy games which relied on XRandR to adjust the screen size to their capacity, Xwayland emulates that using a viewport to scale the (fullscreen, unreparented) window so it appears as if the resolution was changed.

screensaver control

Not sure that anything is needed here. GNOME has been doing screensaver control entirely over D-Bus for many years.