The Role of the Exo Wayland Server in ChromeOS Linux Apps

This article explains the critical role of the Exosphere (exo) Wayland server component within the Chromium codebase and how it enables Linux applications to run seamlessly on ChromeOS. It covers how exo acts as a display server bridge, manages window integration with the native ChromeOS Ash window manager, processes user inputs, and handles high-performance graphics rendering across virtual machines.

What is Exo?

ChromeOS does not use a traditional Linux display server like X11 or a standalone Wayland compositor. Instead, the Chromium browser process itself serves as the system's window manager (Ash) and UI toolkit (Aura).

Located in the //components/exo directory of the Chromium codebase, exo is a Wayland display server implementation built directly on top of Aura and Ash. Its primary job is to allow external applications—specifically Linux apps (Crostini) and Android apps (ARCVM)—to render their interfaces inside the native ChromeOS environment.

Bridging the Virtual Machine

For security reasons, Linux applications on ChromeOS do not run directly on the host operating system. They run inside a Linux container nested within a lightweight virtual machine (VM).

Because the Linux apps are isolated in a VM, they cannot directly access the ChromeOS display hardware. When you launch a Linux app, it communicates with a local proxy compositor inside the VM called Sommelier. Sommelier intercepts the Wayland requests from the Linux app (and translates X11 requests from older apps using XWayland) and forwards them across the VM boundary. Exo sits on the host side of this boundary, receiving those forwarded Wayland protocol requests and executing them on ChromeOS.

Native Window Management Integration

Without exo, Linux applications would have to run inside a single, isolated virtual desktop window, similar to traditional virtual machine software. Exo prevents this by translating Wayland surfaces into native Chromium Aura windows.

Because exo converts these surfaces into standard ChromeOS windows, the Ash window manager can control them just like a Chrome browser window. This allows Linux applications to:

  • Snap to the sides of the screen.
  • Appear as individual icons on the ChromeOS shelf.
  • Move freely between different Virtual Desks.
  • Utilize native ChromeOS window decorations, such as the minimize, maximize, and close buttons.

Graphics and Buffer Sharing

To ensure Linux apps run smoothly and support hardware acceleration, exo manages complex memory sharing. Passing raw pixel data over a virtual network connection would result in severe lag.

Instead, exo utilizes Virtio-GPU and Linux DMA-BUF technologies. When a Linux app renders a frame, the graphics buffer is allocated in shared memory. Exo receives a reference to this buffer via the Wayland protocol and passes it directly to Viz, the Chromium graphics compositor. This zero-copy approach allows the host GPU to draw the Linux application's frame directly onto the Chromebook's screen alongside native UI elements at high frame rates.

Input Routing and System Integration

A display server must also handle user interaction. Exo acts as the reverse bridge for all physical inputs.

When a user clicks a mouse, types on the keyboard, or touches the screen while a Linux app is in focus, the ChromeOS Aura system captures the event. Exo translates these proprietary ChromeOS input events into standard Wayland input events and sends them back through the VM to the Linux application.

Additionally, exo manages system-level integrations such as drag-and-drop operations and clipboard synchronization. This ensures that when you copy text in a Chrome browser tab, exo makes that data available to be pasted directly into a Linux text editor.