Chrome/Chromium on Wayland: The Waylandification project
If you already know what Ozone is, then I am happy to tell you that Chromium for Linux includes Ozone by default now and can be enabled with runtime command line flags. If you are interested in trying Chrome/Chromium with native Wayland support, you are encouraged to download Google Chrome for developers and try Ozone/Wayland by running the browser with the following command line flags:
–-enable-features=UseOzonePlatform -–ozone-platform=wayland
If you don’t know what Ozone is, here’s a brief explanation, before I talk about the history, status and design of this effort.
What is Ozone?
The very first thing that one may think about when they hear “Ozone” is the gas or a thin layer of the Earth’s atmosphere. Well… it is partly correct. In the case of Chromium, it is a platform abstraction layer.
I will not go into many details, but here is the description of that layer from Chromium’s documentation about Ozone:
Ozone is a platform abstraction layer beneath Aura, Chromium’s platform independent windowing system, that is used for low level input and graphics. Once complete, the abstraction will support underlying systems ranging from embedded SoC targets to new X11-alternative window systems on Linux such as Wayland or Mir to bring up Aura Chromium by providing an implementation of the platform interface.
If you are interested in more details, you are welcome to read the project’s documentation.
The Summary of the Design of Ozone/Wayland.
It has been a long time since Antonio Gomes started to work on this project. It started as a research project for our customer – Renesas Electronics, and was based on a former abstraction project with another clever name, mus+ash (pronounced mustache, you can read more about that here – Chromium, ozone, wayland and beyond).
Since that time, the project has been moved to downstream and back to upstream (because of some unknowns related to the mus+ash) and the design of Ozone integration has also been changed.
Currently, the Aura/Platform classes are injected into the Browser process and communicate directly with the underlying Ozone platforms including Wayland. In the browser process, Wayland creates a connection with a Wayland compositor, while in the GPU process, it only draws pixels into the created DMABUFs and neither receives events nor creates surfaces.
Migrating Away From X11-only Legacy Backend.
It is worth mentioning that Igalia has been working on both Ozone/X11 and Ozone/Wayland.
Since June 2020, we have been working on switching Ozone for Linux from needing to be done at compile time to being choosable at runtime. At the moment, one can try Ozone by running Chrome downloaded from the development channel with the following runtime flags:
--enable-features=UseOzonePlatform --ozone-platform=wayland
or
--enable-features=UseOzonePlatform --ozone-platform=x11
That approach is allowing us to gather a bigger audience of users who are willing to test the Ozone capabilities, but also achieve a better feature parity between non-Ozone/X11 and Ozone/X11/Wayland.
That is, most of the features and code paths are shared between the two implementations, and the paths that are not compatible with Ozone are being refactored at the moment.
Once all the incompatible paths are refactored ( just a few of them remain) and all the available test suites are enabled on the Linux/Ozone bot, we will start what is known as a “finch trial”. This allows Ozone to be enabled by default for some percentage of users (about 10%). If the finch trial goes well, the percentage of users will be gradually grown to 100% and we will start removing old non-Ozone/X11 implementation.
Wayland + Tab Drag.
If you’ve been trying it out, you might have already noticed that Ozone/Wayland does not support the Tab Drag feature well enough. The problem is the lack of the protocol for this feature.
At the moment, my colleague Nick Diego is working on the definition of the protocol for tab drag and implementation of that in Chromium.
Unfortunately, Ozone will fallback to x11/xwayland for compositors that do not support the aforementioned protocol. However, once more and more compositors will support that, Chrome will whitelist those compositors.
I would not go into details of that effort here in this blog post, but just rather leave a link to the design document that Nick has created - Tab Dragging on Ozone/Wayland.
Summary.
This blog post was rather a brief summary of the design, feature, and status of the project. Thank you for reading it. Hopefully, when we start a finch trial, I will write another blog telling you how it goes.
Bye!!!