X/Wayland Is Coming Along Nicely, But Work Is Left
Here's my notes from Keith's talk concerning X/Wayland. Nothing from the presentation was particularly new or surprising, but largely summarized information from past mailing list discussions (covered in earlier Phoronix Wayland articles) and past conferences like X@FOSDEM 2012.
- As talked about in previous Phoronix articles, running X applications on Wayland should actually yield performance improvements than X running on the bare graphics card. There should be a net reduction in the number of context switches when running through X/Wayland and as a result better power consumption too.
- While X/Wayland is coming along well, still to be written is a Wayland-specific X window manager as an external application. This will be responsible for translating between ICCCM/EWMH and Wayland and provide the client-side decorations.
- The Wayland changes inside the X Server include around 50 patches to automatically redirect top-level windows, disable input device detection, and to create virtual keyboard/mouse devices with those input devices being sent commands from Wayland's input interpretation.
- The X video driver changes (xf86-video-* driver) changes include disabling native mode-setting, getting mode information from Wayland, ugly hacks for window resize/move (replaced by the yet-to-be-written X/Wayland window manager), and to not acquire the DRM master. At the moment, the xf86-video-intel driver branch is available with this X/Wayland support, but the other popular drivers still need to be updated (Nouveau and Radeon, in particular) with these less-invasive changes.
- Wayland cut-and-paste / drag-and-drop is in good shape with MIME-labeled objects and client-to-client direct transfers.
- When an X application needs to run under Wayland, the Weston compositor will be listening on the X socket, waiting for an incoming X connection, then launch the X Server while passing clients and listen file descriptors. When the X application is done, the xorg-server will be shutdown and Weston will go back waiting for new X connections. Keith would rather have systemd do this work, but Lennart said systemd currently can't start X, so they're using this small hack instead.
- For Wayland proxy support, there's plans for a Wayland proxy that can take the images (buffers) from the local client, pack the data (potentially with compression), and deliver it. This proxy could talk directly to the Wayland server or to another Wayland proxy server. This yet-to-be-written feature could potentially provide acceleration with local GPUs, eliminate most round-trips compared to a proxied X, and use lossy compression. While this has been a debated topic about networked Wayland support, Keith believes this yet-to-come support could provide for better remote application performance with Wayland than X today and is "plausible and pretty usable."
- Remaining Wayland issues including Wayland input support still being in flux (keyboard support, touch-screens, touch-pads, etc), remote Wayland application support, and bringing the X Input 2.2 enhancements to Wayland.
- As someone asked... Wayland will not do any audio support. "Go talk to PulseAudio!" (Reminds me of the earlier X Audio proposal.)
I also recorded an iPhone video of Keith's hour-long video presentation, which will be uploaded later this week and then noted in a later Phoronix article. Now go see what Rebecca Black has to do with Wayland.
While not covered during this presentation, I also learned that a base GNOME Shell 3.x desktop is now running under Wayland by the Intel OTC developers out of London (shared yesterday) who had previously brought up Tizen's Dawati under Wayland. Additionally, there's unofficial talk of NVIDIA looking towards Wayland support for their Tegra SoCs (this morning), which means the NVIDIA Tegra 3 Linux driver having a proper DRM/KMS implementation.
21 Comments
