Posted on 22/12/2017 by Gustavo Noronha
We recently assisted a customer who wanted to upgrade their system from X11 to Wayland. The problem: they use CEF as a runtime for web applications and CEF was not Wayland-ready. They also wanted to have something which was as future-proof and as upstreamable as possible, so the Chromium team’s plans were quite relevant.
Chromium is at the same time very modular and quite monolithic. It supports several platforms and has slightly different code paths in each, while at the same time acting as a desktop shell for Chromium OS. To make it even more complex, the Chromium team is constantly rewriting bits or doing major refactorings.
That means you’ll often find several different and incompatible ways of doing something in the code base. You will usually not find clear and stable interfaces, which is where tools like CEF come in, to provide some stability to users of the framework. CEF neutralizes some of the instability, providing a more stable API.
So we started by looking at 1) where is Chromium headed and 2) what kind of integration CEF needed with Chromium’s guts to work with Wayland? We quickly found that the Chromium team is trying to streamline some of the infrastructure so that it can be better shared among the several use cases, reducing duplication and complexity.
That’s where the mus+ash (pronounced “mustache”) project comes in. It wants to make a better split of the window management and shell functionalities of Chrome OS from the browser while at the same time replacing obsolete IPC systems with Mojo. That should allow a lot more code sharing with the “Linux Desktop” version. It also meant that we needed to get CEF to talk Mus.
Chromium already has Wayland support that was built by Intel a while ago for the Ozone display platform abstraction layer. More recently, the ozone-wayland-dev branch was started by our friends at Igalia to integrate that work with mus+ash, implementing the necessary Mus and Mojo interfaces, window decorations, menus and so on. That looked like the right base to use for our CEF changes.
It took quite a bit of effort and several Collaborans participated in the effort, but we eventually managed to convince CEF to properly start the necessary processes and set them up for running with Mus and Ozone. Then we moved on to make the use cases our customer cared about stable and to port their internal runtime code.
We contributed touch support for the Wayland Ozone backend, which we are in the process of upstreaming, reported a few bugs on the Mus/Ozone integration, and did some debugging for others, which we still need to figure out better fixes for.
For instance, the way Wayland fd polling works does not integrate nicely with the Chromium run loop, since there needs to be some locking involved. If you don’t lock/unlock the display for polling, you may end up in a situation in which you’re told there is something to read and before you actually do the read the GL stack may do it in another thread, causing your blocking read to hang forever (or until there is something to read, like a mouse move). As a work-around, we avoided the Chromium run loop entirely for Wayland polling.
More recently, we have start working on an internal project for adding Mus/Ozone support to Content Shell, which is a test shell simpler than Chromium the browser. We think it will be useful as a test bed for future work that uses Mus/Ozone and the content API but not the browser UI, since it lives inside the Chromium code base. We are looking forward to upstreaming it soon!
PS: if you want to build it and try it out, here are some instructions:
# Check out Google build tools and put them on the path $ git clone https://chromium.googlesource.com/a/chromium/tools/depot_tools.git $ export PATH=$PATH:`pwd`/depot_tools # Check out chromium; note the 'src' after the git command, it is important $ mkdir chromium; cd chromium $ git clone -b cef-wayland https://gitlab.collabora.com/web/chromium.git src $ gclient sync --jobs 16 --with_branch_heads # To use CEF, download it and look at or use the script we put in the repository $ cd src # cef goes inside the chromium source tree $ git clone -b cef-wayland https://gitlab.collabora.com/web/cef.git $ sh ./cef/build.sh # NOTE: you may need to edit this script to adapt to your directory structure $ out/Release_GN_x64/cefsimple --mus --use-views # To build Content Shell you do not need to download CEF, just switch to the branch and build $ cd src $ git checkout -b content_shell_mus_support origin/content_shell_mus_support $ gn args out/Default --args="use_ozone=true enable_mus=true use_xkbcommon=true" $ ninja -C out/Default content_shell $ ./out/Default/content_shell --mus --ozone-platform=wayland
Visit Gustavo's blog.
A well-known Linux kernel developer once said, a poor craftsman famously complains about his tools, but a good craftsman knows how to choose…
The second part of this series takes a more in-depth look at the eBPF VM and program studied in the first part. Having this low level knowledge…
Interested in learning more about low-level specifics of the eBPF stack? Read on as we take a deep dive, from its VM mechanisms and tools,…
It's now possible to run Android applications in the same graphical environment as regular Wayland Linux applications with full 3D acceleration.…
In the previous post I introduced you to the subject of USB gadgets implemented as machines running Linux. In this post, we look at how…
In this tutorial, we'll look at how to create a functional and simple Arch Linux virtual machine image, that can have network access, display…