wayland

seyyed mohammad hashemy

windowing system
display server
compositor
window manager
X11
Xorg
wayland
libwayland
framebuffer

glossary

Xorg architecture

1

Kernel receives input events from a device and translates them into the Linux evdev input event standard.

3

Clients process the event, often leading to UI changes, and send rendering requests back to the X server.

2

X server identifies the window affected by the event and sends it to clients that selected it.

4

X server forwards rendering requests to the hardware driver and calculates the rendering region.

5

A damage event informs the compositor to recomposite the screen part where the window is visible.

7

X server handles rendering requests from the compositor, accounting for overlapping windows and page flipping.

6

The compositor renders the entire screen using the X server, considering the X window contents.

Wayland architecture

1

Kernel forwards events to the compositor, similar to how it's done in X.

3

Client-side rendering occurs in Wayland, and the client sends a request to the compositor indicating the updated region.

2

The compositor uses a scenegraph to determine the correct window for the event, considering transformations.

4

The compositor collects damage requests from clients and recomposites the screen.

5

The compositor can issue an ioctl to schedule a pageflip with KMS for efficient screen updates.

other differences

Security

Networking

Compositing

Wayland rendering

By removing the X server from the picture we also removed the mechanism by which X clients typically render.
DRI2
two ways to render
- Render the new content into a new buffer and tell the compositor to use
- Render the new content into the buffer

backwards compatibility
the Xorg server can be modified to use wayland input devices
Most modern desktops already use an external compositing managerv Using Xwayland is just the same as this, but more efficient .

XWayland

why a new protocol?

a lot of infrastructure has moved from the X server into the kernel (kms,...) or libraries and there is very little left that has to happen in a central server process.

X is 40 years old

there's a tremendous amount of functionality that you must support to claim to speak the X protocol

Modern Design
Improved Security
Better Graphics Rendering:
Easier Development

Wayland Benefits

Boycott Wayland. It breaks everything!

For the first time, we have a chance to avoid that. We can incorporate Wayland's buffer exchange and update models into X. This allows us to push X out of the hotpath between clients and hardware and make it a compatibility option. Now, much of the infrastructure has moved to the kernel or libraries, leaving very little for a central server process.

It offloads a lot of work to each and every window manager
it breaks screen sharing and recording
global hotkeys
NVIDIA support
breaks lots of X specific applications

Text

Wayland adaptation:

gnome, kde, SDL
GTK, Qt
wlroots
- sway
- hyprland
- ...
fedora
ubutntu
Debian
manjaro