From Fedora Project Wiki

No edit summary
No edit summary
Line 127: Line 127:


Quoting Owen in [https://bugzilla.gnome.org/show_bug.cgi?id=759538#c1 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".
Quoting Owen in [https://bugzilla.gnome.org/show_bug.cgi?id=759538#c1 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 ==
* <code>mutter, nvidia drivers</code>
* 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)..




Revision as of 17:50, 22 March 2016

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

remote display

  • protocol, mutter
  • Completion: 50%

Jonas has read-only connections working well, and pointer events working somewhat.

on-screen keyboard

  • protocol, mutter
  • Completion: 0% (TBD)

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.

Rui is supposed to work on this.

graphics tablet support

  • libinput, protocol, libraries, gtk+
  • Completion: 80% (TBD)

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.

Carlos has branches for mutter and gtk+ which will be merged as soon as 3.21 development opens.

A bigger missing piece here is the control-center configuration support.

accessibility: keyboard

  • gtk+, mutter
  • Completion: 0%

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. Moving it to the compositor is not trivial, because we then need to 'neuter' the AccessX implmentation in xwayland.

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.

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.

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.

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

Optional surface IDs

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

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.

Hotplug USB devices

  • mutter
  • Completion: 0%

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

Outputs on secondary GPUs

  • mutter
  • 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 reverse prime.

Remove X11 requirement in mutter

  • mutter
  • Completion: 0%

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


Complete

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


Dropped

Window size hints

  • protocol
  • Completion: 0%

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.

XRandR control of Wayland outputs

  • protocol, Xwayland
  • 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.

screensaver control

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Wayland_features&oldid=439953"