Ubuntu 12.10 Grows Ambitious Wayland Plans
A meeting at the Ubuntu Developer Summit in Oakland just ended concerning a Wayland-based system compositor for Ubuntu 12.10.
The session was about having a system compositor for Ubuntu 12.10 control the entire graphics experience from boot to shut-down. This system compositor is to be powered by Wayland and the Wayland compositor will be based upon the Weston compositor with parts they don't care about being stripped away.
The goal for Ubuntu 12.10 isn't to be running native Wayland clients by default, but to rather still use X11 applications on top of Wayland via XWayland. However, even with the X.Org Server still residing on top, I view this as an extremely ambitious proposal and unlikely to be completed in any formal way for Ubuntu 12.10. If anything, it will likely be some technical preview.
For Ubuntu 12.04 LTS they tried for a Wayland preview and weren't even able to achieve that for the Precise Pangolin. As someone that's been monitoring Wayland for the past five years and the first person to publicly write about Wayland when it was still a very young and experimental project by Kristian, I just don't see this system compositor goal coming close to fruition with Ubuntu 12.10. I've been saying for a while now that it will probably not be until Ubuntu 13.04 that Wayland takes on any really usable form.
Wayland/Weston 1.0 will be out this summer, but that's still far from the final goal in Wayland enablement and there's plenty of custom engineering required to make this system compositor dream happen for Ubuntu. Canonical is known for not their upstream, low-level contributions when it comes to the Linux kernel and graphics drivers, with Wayland it's no different. You can see the top contributors to Wayland and Canonical isn't there. Canonical hasn't made upstream investments in Wayland but right now is largely being led by Intel and community developers.
If a miracle happens and they hit this system compositor goal for Ubuntu 12.10, they will still maintain the current X.Org experience for those with unsupported hardware / drivers -- namely the proprietary AMD and NVIDIA graphics drivers. Canonical also hopes to convince NVIDIA and AMD to support Wayland by writing a special back-end for their drivers.
Canonical is desiring this Ubuntu system compositor to make for more appealing graphics transitions on the desktop and during the boot / log-in process, to disable kernel VT switching, supporting a consistent monitor layout, using the greeter as a secure lock screen, and for other various reasons.
Embedded below are their (very ambitious) notes on the Wayland system compositor discussion.
For binary drivers where they cannot provide a general KMS interface it is recomended we have a defined simple ABI for them to implement to provide a compositor backend (by the end of this process).
This will complicate the boot path, we also have to have the current boot and this new boot form. How are we going to make that testable, we need to test both.
- all boot paths should be mapped out for QA test plans (with and without nvidia proprietary/nouveau)
(initramfs-less, initramfs with LVM, initramfs with crypto, LVM+crypto (single/multi devices), fsck boot path, recovery boot path, etc).
- need wayland plymouth backend initially atleast to minimize changes required to existing boot.
- need to clearly document which scenarios are unsupported
- People running with OSS drivers will be the ones to get this (nouveau, intel, ati).
- hybrid graphics card support will also only work with OSS drivers
- currently installing proprietary (fglrx/nvidia) drivers break other drivers
- the system compositor could help supporting hybrid graphics and graphics switching, but not this cycle, maybe later
- when the interface is ready, ask NVidia and AMD (and binary driver phone vendors where they aren't already doing KMS) to implement it in their binary drivers using the stuff they already have in their binary drivers (perhaps start a conversation on what interface is workable with both before its set in stone)
- the system compositor should be as small as possible and as robust as possible
- how should VT switching be supported?
[raof/apw] Talk at a kernel team level about making VT switching possible, but harder
[robert_ancell] Find canaries for testing this.
[robert_ancell/raof] Talk with foundations about how to minimise the changes between the different boot systems
[robert_ancell/raof] Talk with QA about how to set up testing
[someluckyman] Write a wayland plymouth backend.