(add a couple of bugzilla links) |
|||
Line 169: | Line 169: | ||
One thing we may want to do is show that result for both EGL and GLX contexts, since they may differ. | 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. | |||
== screensaver control == | == screensaver control == |
Revision as of 16:24, 9 December 2015
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 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
remote display
protocol, mutter
- Completion: 20%
Jonas is working on this. He is getting a 'pinos stream' out of gnome-shell.
screencast
mutter, apps
- 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.
primary selection
protocol, gtk+, mutter, Xwayland
- Completion: 20%
- See also: https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
Lyude has a protocol suggestion and a working weston implementation.
dnd actions
protocol, gtk+, mutter, xwayland
- Completion: 80%
Carlos has a protocol proposal, and working implementations. See https://bugzilla.gnome.org/show_bug.cgi?id=755625
kinetic scrolling
protocol, gtk+, mutter
- Completion: 80%
Peter has a protocol proposal and a working implementation. See https://bugzilla.gnome.org/show_bug.cgi?id=756729
input methods
protocol, gtk+, mutter
- Completion: 0% (TBD)
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...
Rui is supposed to work on this.
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.
relative/locking pointer confinement
protocol, libraries
- Completion: 80%
- 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. See https://bugzilla.gnome.org/show_bug.cgi?id=744104
hi-dpi support
protocol, gtk+, mutter
- Completion: 100%
This should be complete, modulo bugs.
attached modal dialogs
gtk+, mutter, protocol
- 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.
- See also: http://lists.freedesktop.org/archives/wayland-devel/2012-December/006637.html, http://lists.freedesktop.org/archives/wayland-devel/2015-November/025726.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.
tablet support
protocol, libraries, gtk+
- 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.
A bigger missing piece here is the control-center configuration support.
startup notification
protocol, libraries, gtk+, mutter
- Completion: 0% (TBD)
clipboard proxy for xwayland
Xwayland
- Completion: 50%
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.
touch proxy for xwayland
protocol, gtk+, mutter, Xwayland
- Completion: 100%
This should be complete, modulo bugs.
accessibility features
protocol, gtk+, mutter
- Completion: 0% (TBD)
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).
Features that need to be reimplemented in the compositor (or gtk+) include:
- 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
mutter, apps
- 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
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.
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.
screensaver control
protocol, mutter, Xwayland, apps
- 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.
Xfree86-VidModeExtension in Xwayland
protocol, Xwayland
- Completion: 0% (TBD)
- 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
XVideo extension in Xwayland
Xwayland
- Completion: 0%
Technically the extension is present, but no adaptors are exposed. This should be wired up to the subsurface protocol if possible.
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.
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.