Contents
Full Wayland support in GNOME
This page collects information about X dependencies in GNOME and feature gaps in Wayland that will have to be overcome to make GNOME work under Wayland without regressions.
A number of these features are currently implemented in the X server, which means that for seamless integration with mixed Wayland and X clients, xwayland needs to do what is necessary to make the X implementations cooperate with the Wayland implementation. Depending on the feature, this may require just turning off the X implementation, or chaining it through to the Wayland interfaces.
Session launching
gdm currently starts the X server for 'graphical sessions', and registers these sessions with the system (logind or ConsoleKit) using their X display name. This needs to be expanded to allow graphical sessions that use Wayland instead of X.
weston employs a small suid helper to get the necessary device access - gnome-shell will need a similar mechanism, and gdm needs to know about it.
ICCCM/EWMH
A lot of the client-wm communication that is codified in the ICCCM and EWMH is available in the wl_shell_surface interface. GNOME shell will have to implement this interface, and possibly add GNOME-specific interfaces.
Here is an incomplete list of things that will be needed:
- initiate window closing, minimizing and other changes from the compositor (for the window close buttons in the overview, and minimization from the classic mode window list)
- information about tiling
associating D-Bus names/paths and surfaces (e.g. for the app menu interface)
XSettings
To be investigated. One option is to just use GSettings directly in GTK+. Another option is to define a settings interface for Wayland, as proposed in this bug.
Display configuration
gnome-settings-daemon uses GnomeRR (which wraps the XRANDR extension) from gnome-desktop to learn about monitors, supported resolutions, etc, and make changes to the display configuration.
GTK+ also uses the XRANDR extension to provide (limited) information about monitor geometry to applications. Some applications use XRANDR directly to find projectors for presentations (gnome-documents, libreoffice).
In the Wayland world, this functionality should be provided by the compositor. It is not expected that the core wayland protocol will include configuration mechanisms, so a private protocol will have to be designed, to be exposed by gnome-shell and used by gnome-control-center. The role of gnome-settings-daemon is not clear yet.
Further details are in /DisplayConfig.
This is done in 3.10.
Idletime
gnome-session uses the XIDLETIME counter (via a wrapper in gnome-desktop) to keep track of when the user last interacted with an input device.
In the Wayland world, the compositor handles all input events anyway (it reads them from evdev and multiplexes them to clients), so it can just keep track of this on its own. If we want to keep gnome-session as the guardian of user idle, an extension interface can provide this information.
This is done in 3.10.
Color management
Needs to be investigated.
We've discussed color management in the past and Pekka drew up this diagram:
http://people.collabora.com/~pq/wayland-color-management-proposal.png
and John Kaare Alsaker has more detailed notes here: https://gist.github.com/Zoxc/3681678
See http://lists.freedesktop.org/archives/wayland-devel/2013-April/008441.html for initial patches.
Keyboard layouts
Wayland clients use libxkbcommon to get access to keyboard layout information.
To be investigated: how does changing keyboard layouts work ?
Input methods
Work has been done to allow a privileged client to translate key events into text events before they are sent out to clients. This allows input methods and on-screen keyboards. This was done to integrate Maliit with Wayland.
Gnome3 primarily uses IBus, whereas GTK+ applications continue to use GTK+ input method modules. Experimental Wayland input method support is added to IBus. This work needs to finalized, tested and upstreamed (WIP) before it can be used in Gnome3. Current approach of capturing key events in the client should be sufficient for first iteration, though input panels might not work properly that way.
GTK+ applications could use a special Wayland input method module to access any input method that is hooked up to the compositor.
Accessibility
The GNOME accessibility stack uses a number of features that are built into X, in particular keyboard accessibility features (SlowKeys, StickyKeys, BounceKeys, MouseKeys), but also simulated button clicks. These will have to be recreated inside the compositor.
The 'visual bell feature is also currently routed through the X server (via XKB), and will have to be replaced by a compositor extension.
at-spi2 uses X in order to listen and inject events (specifically keyboard and mouse events). Anyway, several of the current methods doesn't work (capturing mouse events works, key events seems that not), and in general, X usage inside at-spi2 is a mess (in some cases seems a C&P from at-spi without a real testing). The move to Wayland could be also a moment to clean all that stuff. In relation to key events, it would be good to get a way to monitor key events from Wayland, in order to avoid the current need of key snooping procedures on the toolkit implementation of ATK, as XEVIE tried to do (but failed).
Some of the needs and problems of at-spi2 with respect to X were already summarized on this mail:
That thread included references to previous discussions in relation with Wayland, accessibility and gnome-shell. This mail was forwarded by Alan Coopersmith to the X.Org development list, without answer. During GUADEC, after the two presentations about Wayland, some questions were made on relation with accessibility needs. One answer suggested that if GNOME Shell behaves as a Wayland compositor, some of those features would need to be provided by GNOME Shell as a Wayland extension. Anyway, that was a quick-after-presentation-answer and the speaker recognized that some deeper discusion would be needed. Probably it is a good time to send a similar mail but to wayland development lists (and forget about X).
During Montreal Summit Accessibility team did a deep testing of the platfom under wayland, tracking current situation and opening bugs. More info here Accessibility/Wayland
Global keyboard shortcuts
In 3.8, the grabbing has been moved from gnome-settings-daemon into GNOME shell, which makes it very easy to keep this functionality working under Wayland: Simply replace the grabs by an event filter inside the compositor.
Pointer barriers
gnome-shell uses the recently added XInput/XFixes APIs for pointer barriers.
In the Wayland world, the equivalent functionality has to be implemented directly in the compositor, no API is needed.
Wacom tablet support
The GNOME control-center has support for configuring Wacom tablets. These tablets generate XInput events that let clients use them like mice.
Wayland does not support Wacom tablets currently.
Joypad support
Games commonly use evdev directly for this. The can keep doing that under Wayland, until an extension interface is added that provides this support.
ClutterGTK
ClutterGTK relies on being able to make a child XWindow and creates a GL context to render to that. This isn't going to work in Wayland. Perhaps the Wayland sub-surface work could help with this. It will break Cheese and probably some of the games.
Alternatively, we can render the embedded GtkWidget into a Cairo x11 surface, and turn it into a CoglTexture; this approach will imply a copy, but that's what happens with embedded widgets in web browsers, and they don't seem to be awful at that.
gstreamer
There is a libva backend for Wayland, and gstreamer has support for it. weston uses YUV overlays for video when possible; maybe gnome-shell should do the same.