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
X
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
Text
X is dead long live the Wayland
- KDE X. org is feature freaze
- GTK is considering droping X. org support
Thank You!
Questions?
- https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
- https://wayland.freedesktop.org/
- https://en.wikipedia.org/wiki/Wayland_(protocol)
- https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-feature-frozen/
references
Wayland
By Mohammad Hashemy
