From Fedora Project Wiki

No edit summary
Line 137: Line 137:
* Completion: 0% (TBD)
* 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.
* 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.
== Device and Driver information ==
* <code>EGL api, mutter, gnome-control-center</code>
* Completion: 0% (TBD)
We want to show the same kind of GPU information that we get from
GL_RENDERER under X11. Currently EGL does not have any way to query
that information. Once that is in place, mutter should export it over
D-Bus, so gnome-control-center can show it in the Details panel.
Currently, it just says "Wayland" there.


== screensaver control ==
== screensaver control ==

Revision as of 13:57, 24 November 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

Chandler is working on this. He has a protocol suggestion and a working weston implementation.

input methods

  • protocol, gtk+, mutter
  • Completion: 0% (TBD)
Note.png
FIXME
I have no idea where we stand wrt input methods nor what is really meant by that

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)
Note.png
FIXME
Not sure if we'd need a new app for that.

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

Jonas has a protocol and implementations. Will land in Wayland 1.10.

hi-dpi support

  • protocol, gtk+, mutter
  • Completion: 100%
Note.png
FIXME
Not sure what is meant by that, Wayland supports scaling of surfaces and mutter uses that afaik.

This should be complete, modulo bugs.

attached modal dialogs

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%
Note.png
FIXME
Not sure what is meant by that, touch was added in Wayland and Xwayland by Carlos.

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.

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.

Device and Driver information

  • EGL api, mutter, gnome-control-center
  • Completion: 0% (TBD)

We want to show the same kind of GPU information that we get from GL_RENDERER under X11. Currently EGL does not have any way to query that information. Once that is in place, mutter should export it over D-Bus, so gnome-control-center can show it in the Details panel.

Currently, it just says "Wayland" there.

screensaver control

Xfree86-VidModeExtension in Xwayland

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.