The WindowService2(?) of CrOS

Recently, WS was replaced with WS2:

• 1144255 window-service: removes mus_demo, test_wm, and some unnecessary deps

• Issue 865689  Remove window-service

I ran mus_demo to test ozone-gbm, but now it's gone. :-( So, I need to figure it out what is the difference between WS1 and WS2.

What is the Window Service of ChromeOS? Window Service is a kind of Window Compositor like Weston. It is a separate process from the browser process in CrOS. Some of CrOS features are part of the browser process, but those features will be a separate process using the WindowService.

For more details, see https://cs.chromium.org/chromium/src/services/ws/README.md

"Clients establish a connection to the WindowService by configuring Aura with a mode of MUS. See aura::Env::Mode for details. The WindowService provides a way for one client to embed another client in a specific window (application composition). Embedding establishes a connection to a new client and provides the embedded client with a window to use. See the mojom for more details. For example, on Chrome OS, Ash uses the WindowService to enable separate processes, such as the tap_visualizer, to connect to the WindowService. The tap_visualizer is a client of the WindowService. The tap_visualizer uses the WindowService to create and manage windows, receive events, and ultimately draw to the screen (using Viz). This is mostly seamless to the tap_visualizer. The tap_visualizer configures Views to use Mus, which results in Views and Aura, using the WindowService."

CrOS is now becoming more like a regular desktop. I'm not sure this is a good decision.

Linux container for ChromeOS

Recently, ChromeOS started to support Linux applications on ChomeOS. Google hasn't allowed ChromeOS to run native applications due to security reason. Finally, they found a way to support Linux application through the container technology.

It is worth to read a discussion on CrOSVM on Hacker News because the original author joined the discussion. Here is the article about ChromeOS Linux container.
https://www.zdnet.com/article/chrome-os-could-be-getting-containers-for-running-linux-vms/

There is a Youtube video:
https://www.youtube.com/watch?v=s9mrR2tqVbQ

Here is the readme about CrOSVM.
https://chromium.googlesource.com/chromiumos/platform/crosvm/+/837b59f2d97b005ef84ac36efa97530c1bbf2a79/README.md

The interesting thing is that it is implemented with Rust. Google now seriously uses Rust of their product, which is a good news for the Rust community.

Making Use Of Chrome's Ozone-GBM Intel Graphics Support On The Linux Desktop

Recently, I published a blog article about making Use Of Chrome's Ozone-GBM Intel Graphics Support On The Linux Desktop. This is about using ChromeOS graphics stack for a regular Linux system.  This article was also mentioned in Phoronix.

Originally, my old colleague started working on this a long time ago, but it has been broken since then. So I have been trying to enable ozone-gbm on a Linux system because this solution would be useful for embedded systems. I'm making a Yocto recipe for this and will open it soon.

Rust & DRM

I was surprised that there are many low-level graphics projects written in Rust and I started looking into one of them: drm-rs. Then, I added an example for handling page-flip event.

drm-rs is a subproject of Smithay that is a wayland compositor written in Rust. It allows Rust applications to access the Direct Rendering Manger(DRM), a subsystem of the Linux Kernel. So, we could directly paint something into a frame buffer and render it on the display using DRM APIs.

BlinkOn9

I attended BlinkOn9 from April 18 to 19, 2019. Here is the official page: bit.ly/blinkon9-info, presentations, and Lightning Talks.

At this conference, I talked about acelerating graphics performance with ozone-gbm on Intel based Linux desktop systems: explained what kind of hardware accelerations have been applied to Intel -based Chromebook and how we can use them on a Linux desktop.

Here is a demo video on Youtube: