December 22, 2017
TL;DR: We have patches for CEF to enable its usage on Wayland and X11 through the Mus/Ozone infrastructure that is to become Chromium’s streamlined future. And also for Content Shell!
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 while back I presented USB 2.0 host support that was added to U-boot for the Radxa Rock-5B RK3588 Rockchip board. This time, USB 3.0 was…
Work continues on the Radxa ROCK5B RK388, as PCIe and RTL8125B networking support in U-boot have now been added. Publishing code as Open…
NVK, an open-source Vulkan driver for NVIDIA hardware that is part of Mesa, now supports the Vulkan extension VK_KHR_multiview.
The beauty of Open Source is that we can reuse code written by many other people, keep their authorship, and credit them for their work,…
Want to develop your Meson project in a modern IDE? Make sure to install Meson VSCode extension which is now fully functional with the recent…
Labeling errors are common in present open-source 3D perception datasets, which could have impactful consequences. To tackle this issue,…
Add a Comment