diff --git a/2020-07-dateindex.html b/2020-07-dateindex.html index 366f5e5..5e8cad1 100644 --- a/2020-07-dateindex.html +++ b/2020-07-dateindex.html @@ -141,7 +141,7 @@

July 2020

diff --git a/2020-08-dateindex.html b/2020-08-dateindex.html index 5dc11a8..fb90269 100644 --- a/2020-08-dateindex.html +++ b/2020-08-dateindex.html @@ -54,7 +54,7 @@

August 2020

diff --git a/2020-09-dateindex.html b/2020-09-dateindex.html index 6c68ef8..1a83740 100644 --- a/2020-09-dateindex.html +++ b/2020-09-dateindex.html @@ -51,7 +51,7 @@

September 2020

diff --git a/2020-10-dateindex.html b/2020-10-dateindex.html index dae8aaa..8f9288d 100644 --- a/2020-10-dateindex.html +++ b/2020-10-dateindex.html @@ -51,7 +51,7 @@

October 2020

diff --git a/2020-11-dateindex.html b/2020-11-dateindex.html index 1ccfda0..6c79775 100644 --- a/2020-11-dateindex.html +++ b/2020-11-dateindex.html @@ -54,7 +54,7 @@

November 2020

diff --git a/2020-12-dateindex.html b/2020-12-dateindex.html index 9279d9a..ddc475b 100644 --- a/2020-12-dateindex.html +++ b/2020-12-dateindex.html @@ -57,7 +57,7 @@

December 2020

diff --git a/2021-01-dateindex.html b/2021-01-dateindex.html index d29410b..2b37d72 100644 --- a/2021-01-dateindex.html +++ b/2021-01-dateindex.html @@ -54,7 +54,7 @@

January 2021

diff --git a/2021-02-dateindex.html b/2021-02-dateindex.html index 8b0620a..d410170 100644 --- a/2021-02-dateindex.html +++ b/2021-02-dateindex.html @@ -57,7 +57,7 @@

February 2021

diff --git a/2021-03-dateindex.html b/2021-03-dateindex.html index 82f4e88..0a40097 100644 --- a/2021-03-dateindex.html +++ b/2021-03-dateindex.html @@ -48,7 +48,7 @@

March 2021

diff --git a/2021-04-dateindex.html b/2021-04-dateindex.html index 6e3e65c..c2ed6be 100644 --- a/2021-04-dateindex.html +++ b/2021-04-dateindex.html @@ -57,7 +57,7 @@

April 2021

diff --git a/2021-05-dateindex.html b/2021-05-dateindex.html index 2db14ec..45e08a5 100644 --- a/2021-05-dateindex.html +++ b/2021-05-dateindex.html @@ -57,7 +57,7 @@

May 2021

diff --git a/2021-06-dateindex.html b/2021-06-dateindex.html index a24e2f3..6efe564 100644 --- a/2021-06-dateindex.html +++ b/2021-06-dateindex.html @@ -69,7 +69,7 @@

June 2021

diff --git a/2021-08-dateindex.html b/2021-08-dateindex.html index 63ebb79..0472db7 100644 --- a/2021-08-dateindex.html +++ b/2021-08-dateindex.html @@ -48,7 +48,7 @@

August 2021

diff --git a/2021-09-dateindex.html b/2021-09-dateindex.html index 675dd00..b187e26 100644 --- a/2021-09-dateindex.html +++ b/2021-09-dateindex.html @@ -51,7 +51,7 @@

September 2021

diff --git a/2021-10-dateindex.html b/2021-10-dateindex.html index e021189..234d783 100644 --- a/2021-10-dateindex.html +++ b/2021-10-dateindex.html @@ -48,7 +48,7 @@

October 2021

diff --git a/2021-11-dateindex.html b/2021-11-dateindex.html index 6a1b338..591377f 100644 --- a/2021-11-dateindex.html +++ b/2021-11-dateindex.html @@ -63,7 +63,7 @@

November 2021

diff --git a/2021-12-dateindex.html b/2021-12-dateindex.html index e407ec0..85db4c5 100644 --- a/2021-12-dateindex.html +++ b/2021-12-dateindex.html @@ -48,7 +48,7 @@

December 2021

diff --git a/2022-01-dateindex.html b/2022-01-dateindex.html index a6ab4e6..76b025f 100644 --- a/2022-01-dateindex.html +++ b/2022-01-dateindex.html @@ -54,7 +54,7 @@

January 2022

diff --git a/2022-02-dateindex.html b/2022-02-dateindex.html index c7cb162..ca3b949 100644 --- a/2022-02-dateindex.html +++ b/2022-02-dateindex.html @@ -57,7 +57,7 @@

February 2022

diff --git a/2022-03-dateindex.html b/2022-03-dateindex.html index 305aa02..09f50e7 100644 --- a/2022-03-dateindex.html +++ b/2022-03-dateindex.html @@ -48,7 +48,7 @@

March 2022

diff --git a/2022-04-dateindex.html b/2022-04-dateindex.html index 34003ec..98e2025 100644 --- a/2022-04-dateindex.html +++ b/2022-04-dateindex.html @@ -48,7 +48,7 @@

April 2022

diff --git a/2022-05-dateindex.html b/2022-05-dateindex.html index 10dd3aa..cacc458 100644 --- a/2022-05-dateindex.html +++ b/2022-05-dateindex.html @@ -48,7 +48,7 @@

May 2022

diff --git a/2022-06-dateindex.html b/2022-06-dateindex.html index 481435a..0489fac 100644 --- a/2022-06-dateindex.html +++ b/2022-06-dateindex.html @@ -57,7 +57,7 @@

June 2022

diff --git a/2022-07-dateindex.html b/2022-07-dateindex.html index ad53916..d053e43 100644 --- a/2022-07-dateindex.html +++ b/2022-07-dateindex.html @@ -54,7 +54,7 @@

July 2022

diff --git a/2022-08-dateindex.html b/2022-08-dateindex.html index bafcfb6..7874569 100644 --- a/2022-08-dateindex.html +++ b/2022-08-dateindex.html @@ -96,7 +96,7 @@

August 2022

diff --git a/2022-09-dateindex.html b/2022-09-dateindex.html index 1bb1b8c..aee1b20 100644 --- a/2022-09-dateindex.html +++ b/2022-09-dateindex.html @@ -75,7 +75,7 @@

September 2022

diff --git a/2022-10-dateindex.html b/2022-10-dateindex.html index 97614b1..75bb1a1 100644 --- a/2022-10-dateindex.html +++ b/2022-10-dateindex.html @@ -48,7 +48,7 @@

October 2022

diff --git a/2022-11-dateindex.html b/2022-11-dateindex.html index d650428..c1ea794 100644 --- a/2022-11-dateindex.html +++ b/2022-11-dateindex.html @@ -51,7 +51,7 @@

November 2022

diff --git a/2022-12-dateindex.html b/2022-12-dateindex.html index d72a1c1..cfb108c 100644 --- a/2022-12-dateindex.html +++ b/2022-12-dateindex.html @@ -48,7 +48,7 @@

December 2022

diff --git a/2023-01-dateindex.html b/2023-01-dateindex.html index e60c817..62cc1fc 100644 --- a/2023-01-dateindex.html +++ b/2023-01-dateindex.html @@ -60,7 +60,7 @@

January 2023

diff --git a/2023-02-dateindex.html b/2023-02-dateindex.html index 91e87f4..2b5bef4 100644 --- a/2023-02-dateindex.html +++ b/2023-02-dateindex.html @@ -48,7 +48,7 @@

February 2023

diff --git a/2023-03-dateindex.html b/2023-03-dateindex.html index 693cc90..1106fb4 100644 --- a/2023-03-dateindex.html +++ b/2023-03-dateindex.html @@ -51,7 +51,7 @@

March 2023

diff --git a/2023-04-dateindex.html b/2023-04-dateindex.html index b789323..b23e3cd 100644 --- a/2023-04-dateindex.html +++ b/2023-04-dateindex.html @@ -51,7 +51,7 @@

April 2023

diff --git a/2023-05-dateindex.html b/2023-05-dateindex.html index 053abb4..b94711a 100644 --- a/2023-05-dateindex.html +++ b/2023-05-dateindex.html @@ -60,7 +60,7 @@

May 2023

diff --git a/2023-06-dateindex.html b/2023-06-dateindex.html index b7c7096..6f30f33 100644 --- a/2023-06-dateindex.html +++ b/2023-06-dateindex.html @@ -63,7 +63,7 @@

June 2023

diff --git a/2023-07-dateindex.html b/2023-07-dateindex.html index 1d8f9a4..b61d249 100644 --- a/2023-07-dateindex.html +++ b/2023-07-dateindex.html @@ -57,7 +57,7 @@

July 2023

diff --git a/2023-08-dateindex.html b/2023-08-dateindex.html index 38e09dc..cc68647 100644 --- a/2023-08-dateindex.html +++ b/2023-08-dateindex.html @@ -51,7 +51,7 @@

August 2023

diff --git a/2023-09-dateindex.html b/2023-09-dateindex.html index d5fb39b..87b13e1 100644 --- a/2023-09-dateindex.html +++ b/2023-09-dateindex.html @@ -60,7 +60,7 @@

September 2023

diff --git a/2023-10-dateindex.html b/2023-10-dateindex.html index 0ca5535..538a16c 100644 --- a/2023-10-dateindex.html +++ b/2023-10-dateindex.html @@ -48,7 +48,7 @@

October 2023

diff --git a/2023-11-dateindex.html b/2023-11-dateindex.html index c9d666d..0faecb5 100644 --- a/2023-11-dateindex.html +++ b/2023-11-dateindex.html @@ -51,7 +51,7 @@

November 2023

diff --git a/2023-12-dateindex.html b/2023-12-dateindex.html index ddedfe7..86df44f 100644 --- a/2023-12-dateindex.html +++ b/2023-12-dateindex.html @@ -54,7 +54,7 @@

December 2023

diff --git a/2024-01-dateindex.html b/2024-01-dateindex.html index cacba6f..47a16d0 100644 --- a/2024-01-dateindex.html +++ b/2024-01-dateindex.html @@ -68,7 +68,7 @@

January 2024

diff --git a/2024-02-dateindex.html b/2024-02-dateindex.html index 38583fc..b6e74c3 100644 --- a/2024-02-dateindex.html +++ b/2024-02-dateindex.html @@ -51,7 +51,7 @@

February 2024

diff --git a/2024-03-dateindex.html b/2024-03-dateindex.html index 1351f4a..7eb53fd 100644 --- a/2024-03-dateindex.html +++ b/2024-03-dateindex.html @@ -60,7 +60,7 @@

March 2024

diff --git a/2024-04-dateindex.html b/2024-04-dateindex.html index 5c0440b..43fcb14 100644 --- a/2024-04-dateindex.html +++ b/2024-04-dateindex.html @@ -48,7 +48,7 @@

April 2024

diff --git a/2024-05-dateindex.html b/2024-05-dateindex.html index a4bd95c..fe2d1bc 100644 --- a/2024-05-dateindex.html +++ b/2024-05-dateindex.html @@ -51,7 +51,7 @@

May 2024

diff --git a/2024-06-dateindex.html b/2024-06-dateindex.html index 0ce9293..30b082a 100644 --- a/2024-06-dateindex.html +++ b/2024-06-dateindex.html @@ -57,7 +57,7 @@

June 2024

diff --git a/2024-07-dateindex.html b/2024-07-dateindex.html index d55a020..a70ee5f 100644 --- a/2024-07-dateindex.html +++ b/2024-07-dateindex.html @@ -51,7 +51,7 @@

July 2024

diff --git a/2024-08-dateindex.html b/2024-08-dateindex.html index c2e0ab3..bba17fc 100644 --- a/2024-08-dateindex.html +++ b/2024-08-dateindex.html @@ -48,7 +48,7 @@

August 2024

diff --git a/2024-09-dateindex.html b/2024-09-dateindex.html index 821086a..ac87b3c 100644 --- a/2024-09-dateindex.html +++ b/2024-09-dateindex.html @@ -54,7 +54,7 @@

September 2024

diff --git a/2024-10-dateindex.html b/2024-10-dateindex.html index a536e27..ee165ef 100644 --- a/2024-10-dateindex.html +++ b/2024-10-dateindex.html @@ -54,7 +54,7 @@

October 2024

diff --git a/2024-11-dateindex.html b/2024-11-dateindex.html index 9d88278..f4c2d2c 100644 --- a/2024-11-dateindex.html +++ b/2024-11-dateindex.html @@ -45,7 +45,7 @@

November 2024

diff --git a/2024-12-dateindex.html b/2024-12-dateindex.html new file mode 100644 index 0000000..44fffd1 --- /dev/null +++ b/2024-12-dateindex.html @@ -0,0 +1,55 @@ + + + + + Kevin Boone: December 2024 + + + + + + + + + + + + +
+Kevin Boone +
+ + + +
+ + + + +

December 2024

+ +
Wayland from the ground up

Wayland isn't new, but many of us have been able to avoid it until recently. With many Linux distributions now pushing Wayland hard -- even for the Raspberry Pi -- it's getting harder to justify ignoring it. This article is for people who have been hoping until now that Wayland will go away, particularly X developers, and don't know much about how it works

Categories: Linux

+
+ + +

+
+ + + + + + + diff --git a/Arduino-groupindex.html b/Arduino-groupindex.html index bab7de2..cb5f8db 100644 --- a/Arduino-groupindex.html +++ b/Arduino-groupindex.html @@ -59,7 +59,7 @@

Arduino

diff --git a/C-groupindex.html b/C-groupindex.html index 03dee3f..c3a12a2 100644 --- a/C-groupindex.html +++ b/C-groupindex.html @@ -155,7 +155,7 @@

C

diff --git a/Java-groupindex.html b/Java-groupindex.html index 98bb2b0..a83bb8b 100644 --- a/Java-groupindex.html +++ b/Java-groupindex.html @@ -122,7 +122,7 @@

Java

diff --git a/Linux-groupindex.html b/Linux-groupindex.html index d570b8b..3134564 100644 --- a/Linux-groupindex.html +++ b/Linux-groupindex.html @@ -193,6 +193,9 @@

Linux

A few interesting features of Vim, part 1

The Vim text editor is almost ubiquitous on Linux systems, and for good reasons. This is the first article in a series which seeks to uncover some handy features of Vim, that don't seem to be widely known.

Categories: Linux

+
Wayland from the ground up

Wayland isn't new, but many of us have been able to avoid it until recently. With many Linux distributions now pushing Wayland hard -- even for the Raspberry Pi -- it's getting harder to justify ignoring it. This article is for people who have been hoping until now that Wayland will go away, particularly X developers, and don't know much about how it works

Categories: Linux

+
+

@@ -200,7 +203,7 @@

Linux

diff --git a/Lua-groupindex.html b/Lua-groupindex.html index 4fc5511..df552c7 100644 --- a/Lua-groupindex.html +++ b/Lua-groupindex.html @@ -47,7 +47,7 @@

Lua

diff --git a/OpenShift-groupindex.html b/OpenShift-groupindex.html index 3d1a1d0..d1d9d7d 100644 --- a/OpenShift-groupindex.html +++ b/OpenShift-groupindex.html @@ -65,7 +65,7 @@

OpenShift

diff --git a/Perl-groupindex.html b/Perl-groupindex.html index 74fe516..6164204 100644 --- a/Perl-groupindex.html +++ b/Perl-groupindex.html @@ -44,7 +44,7 @@

Perl

diff --git a/Pico-groupindex.html b/Pico-groupindex.html index bb39d18..09a8b4b 100644 --- a/Pico-groupindex.html +++ b/Pico-groupindex.html @@ -80,7 +80,7 @@

Pico

diff --git a/Raspberry_Pi-groupindex.html b/Raspberry_Pi-groupindex.html index d997c06..91d10ee 100644 --- a/Raspberry_Pi-groupindex.html +++ b/Raspberry_Pi-groupindex.html @@ -140,7 +140,7 @@

Raspberry Pi

diff --git a/TDMTLTAM-groupindex.html b/TDMTLTAM-groupindex.html index b10e277..eb355e9 100644 --- a/TDMTLTAM-groupindex.html +++ b/TDMTLTAM-groupindex.html @@ -83,7 +83,7 @@

TDMTLTAM

diff --git a/Z80-groupindex.html b/Z80-groupindex.html index 0c71ffe..629e7f5 100644 --- a/Z80-groupindex.html +++ b/Z80-groupindex.html @@ -107,7 +107,7 @@

Z80

diff --git a/articles.html b/articles.html index 45cea99..1269b6b 100644 --- a/articles.html +++ b/articles.html @@ -81,6 +81,7 @@

Articles by date

2024

+December 2024
November 2024
October 2024
September 2024
@@ -156,7 +157,7 @@

2020

diff --git a/assembly-groupindex.html b/assembly-groupindex.html index 7797d8f..3fe45c7 100644 --- a/assembly-groupindex.html +++ b/assembly-groupindex.html @@ -47,7 +47,7 @@

Assembly

diff --git a/command-line_hacking-groupindex.html b/command-line_hacking-groupindex.html index 9b778eb..2142c20 100644 --- a/command-line_hacking-groupindex.html +++ b/command-line_hacking-groupindex.html @@ -74,7 +74,7 @@

Command-line hacking

diff --git a/containers-groupindex.html b/containers-groupindex.html index c67fe22..138264b 100644 --- a/containers-groupindex.html +++ b/containers-groupindex.html @@ -50,7 +50,7 @@

Containers

diff --git a/degoogling-groupindex.html b/degoogling-groupindex.html index ed4d9a1..3419abd 100644 --- a/degoogling-groupindex.html +++ b/degoogling-groupindex.html @@ -56,7 +56,7 @@

Degoogling

diff --git a/education-groupindex.html b/education-groupindex.html index 591bec6..6fcb5d0 100644 --- a/education-groupindex.html +++ b/education-groupindex.html @@ -62,7 +62,7 @@

Education

diff --git a/electronics-groupindex.html b/electronics-groupindex.html index 4c606f4..1043a4c 100644 --- a/electronics-groupindex.html +++ b/electronics-groupindex.html @@ -110,7 +110,7 @@

Electronics

diff --git a/embedded_computing-groupindex.html b/embedded_computing-groupindex.html index bde40d9..ee774e0 100644 --- a/embedded_computing-groupindex.html +++ b/embedded_computing-groupindex.html @@ -179,7 +179,7 @@

Embedded computing

diff --git a/feed.xml b/feed.xml index d5f8fad..683d2f9 100644 --- a/feed.xml +++ b/feed.xml @@ -9,7 +9,17 @@ https://kevinboone.me https://kevinboone.me/img/favicon.jpg -Fri, 22 Nov 2024 15:12:01 GMT +Sun, 01 Dec 2024 12:03:46 GMT + +Wayland from the ground up +https://kevinboone.me/wayland_ground_up.html +https://kevinboone.me/wayland_ground_up.html +Wayland isn't new, but many of us have been able to avoid it until recently. With many Linux distributions now pushing Wayland hard -- even for the Raspberry Pi -- it's getting harder to justify ignoring it. This article is for people who have been hoping until now that Wayland will go away, particularly X developers, and don't know much about how it works + + +Sun, 01 Dec 2024 11:57:07 GMT + + Why systemd is a problem for embedded Linux https://kevinboone.me/systemd_embedded.html diff --git a/gateaux.html b/gateaux.html index 5ffaeed..880cecf 100644 --- a/gateaux.html +++ b/gateaux.html @@ -160,7 +160,7 @@

The Gâteaux differential

ε to zero:

-Maple screenshot +Maple screenshot

Subtituting back into the integral gives us the Gâteaux differential: diff --git a/general_computing-groupindex.html b/general_computing-groupindex.html index 3d1c6e3..7d4c2c4 100644 --- a/general_computing-groupindex.html +++ b/general_computing-groupindex.html @@ -104,7 +104,7 @@

General computing

diff --git a/hifi-groupindex.html b/hifi-groupindex.html index 55fdfb1..1298318 100644 --- a/hifi-groupindex.html +++ b/hifi-groupindex.html @@ -92,7 +92,7 @@

Hifi

diff --git a/img/wayland_00.png b/img/wayland_00.png new file mode 100644 index 0000000..fdf22d9 Binary files /dev/null and b/img/wayland_00.png differ diff --git a/img/wayland_01.png b/img/wayland_01.png new file mode 100644 index 0000000..c5160e8 Binary files /dev/null and b/img/wayland_01.png differ diff --git a/img/wayland_02.png b/img/wayland_02.png new file mode 100644 index 0000000..536d567 Binary files /dev/null and b/img/wayland_02.png differ diff --git a/law-groupindex.html b/law-groupindex.html index 6804be3..dd40e3b 100644 --- a/law-groupindex.html +++ b/law-groupindex.html @@ -53,7 +53,7 @@

Law

diff --git a/mathematics-groupindex.html b/mathematics-groupindex.html index c96673c..9b7fc12 100644 --- a/mathematics-groupindex.html +++ b/mathematics-groupindex.html @@ -98,7 +98,7 @@

Mathematics

diff --git a/middleware-groupindex.html b/middleware-groupindex.html index 782dfdd..5a93677 100644 --- a/middleware-groupindex.html +++ b/middleware-groupindex.html @@ -104,7 +104,7 @@

Middleware

diff --git a/music-groupindex.html b/music-groupindex.html index cd2f7df..84ce320 100644 --- a/music-groupindex.html +++ b/music-groupindex.html @@ -59,7 +59,7 @@

Music

diff --git a/pi_desktop_media.html b/pi_desktop_media.html index aa6bd0a..079a852 100644 --- a/pi_desktop_media.html +++ b/pi_desktop_media.html @@ -70,7 +70,7 @@

Yet another desktop Raspberry Pi media player

In practice, though, it's hard to buy a local (not network) media player in the form of a desktop device. There are some nice network media players, like the -Cambridge Audio CXN V2 that will play from a UPnP +Cambridge Audio CXN V2 that will play from a UPnP audio server. So I guess I could set up a Raspberry Pi with a big USB memory stick and run a UPnP server on it. There are two problems with this approach, however. First, equipment like this is shockingly diff --git a/retrocomputing-groupindex.html b/retrocomputing-groupindex.html index ec4d4dd..2e498bb 100644 --- a/retrocomputing-groupindex.html +++ b/retrocomputing-groupindex.html @@ -134,7 +134,7 @@

Retrocomputing

diff --git a/science-groupindex.html b/science-groupindex.html index 2ee9ebf..daad9c2 100644 --- a/science-groupindex.html +++ b/science-groupindex.html @@ -44,7 +44,7 @@

Science

diff --git a/science_and_technology-groupindex.html b/science_and_technology-groupindex.html index bd68fce..6ab5e65 100644 --- a/science_and_technology-groupindex.html +++ b/science_and_technology-groupindex.html @@ -89,7 +89,7 @@

Science and technology

diff --git a/security-groupindex.html b/security-groupindex.html index 948ef52..a77d075 100644 --- a/security-groupindex.html +++ b/security-groupindex.html @@ -62,7 +62,7 @@

Security

diff --git a/snake_oil-groupindex.html b/snake_oil-groupindex.html index 1436619..2371c4b 100644 --- a/snake_oil-groupindex.html +++ b/snake_oil-groupindex.html @@ -68,7 +68,7 @@

Snake oil

diff --git a/software_development-groupindex.html b/software_development-groupindex.html index 4fca899..2a40b17 100644 --- a/software_development-groupindex.html +++ b/software_development-groupindex.html @@ -191,7 +191,7 @@

Software development

diff --git a/wayland_ground_up.html b/wayland_ground_up.html new file mode 100644 index 0000000..c3ce5b6 --- /dev/null +++ b/wayland_ground_up.html @@ -0,0 +1,512 @@ + + + + + Kevin Boone: Wayland from the ground up + + + + + + + + + + + + +
+Kevin Boone +
+ + + +
+ + + +

+

Wayland from the ground up

+

+

If, like me, you’ve been ignoring Wayland in the hope that it will +just go away, you’re out of luck. Most Linux distributions now want to +use Wayland by default – even Raspberry Pi OS. The Fedora project has, +for better or worse, reached the point where good old X.org won’t even +be available by default in new installations.

+

I suspect that the move to Wayland will be invisible to most end +users – so long as it works – at least on desktop systems. If you’re a +Linux developer, though, or even a sophisticated end user, there’s no +longer any way to avoid getting to grips with Wayland.

+

In this article I explain, from the very basics, how Wayland works, +and what makes it different from X.org. I make no comment on whether I +think Wayland is a Good Thing, or a Bad Thing; but I do have views on +this, and I fear that my biases might become apparent. Perhaps they +already have.

+

A bit of history

+

I divide the task of understanding Wayland into two parts: +understanding how it works, and understanding why it works as +it does. Wayland embodies some design decisions that, to my mind, are +incomprehensible without at least some understanding of its place in the +overall lineage of graphical computing.

+

The first revision of the X11 protocol, published in 1987, defined a +way for application programs to communicate with graphical terminals. +This was a time when, in the world of high-performance computing, +‘processing’ and ‘user interaction’ took place on entirely different +pieces of hardware, connected by network cables. The ‘processing’ part +was typically a minicomputer, running a multi-user, multi-tasking +operating system like Unix. The ‘user interaction’ part was a terminal +of some kind: initially text terminals, and then graphics terminals. A +graphics terminal that supported X11 was, and still is, usually called +an ‘X terminal’, but ‘X server’ is a more general term. In the X world, +the
+‘server’ is whatever provides the user interface; a ‘client’ is any +application that works with that server. Under X11, the whole +infrastructure – the X server and its supporting client applications – +became known as the ‘X Window System’, or just ‘X’.

+

PCs – relative newcomers to the computing world at that time – did +not work in the same way at all. A desktop PC usually had, and still +has, a graphics adapter that connects directly to a monitor, and its own +input devices. Applications communicate with these devices directly, or +via the operating system. Initially, X11 had relatively little relevance +to PCs.

+

The last major revision on X11, ‘X11R6’, was published in 1994. X11R6 +is a fabulously complex set of specifications, covering all aspects of +interaction between a graphical terminal and its client applications. It +defines, of course, how an application creates and manages screen +windows. But it also specifies the handling of fonts and cursors, many +methods for drawing lines and shapes, how applications can communicate +with one another via their windows, and so on.

+

By the early 90s, Linux was well established, and there was +increasing interest in running graphical applications. Linux +could have gone the same way as Microsoft Windows: it could +have defined an application programming interface by which software +could interact with a locally-connected, windowed screen display. That +this did not happen is probably because there was a already a stack of +software for X, which could readily be ported to Linux – well, more +readily than re-writing it all in Windows style. The problem was that +Linux ran on PCs with locally-attached displays, not separate graphics +terminals as X assumed. The solution – which no doubt seemed a good one +at the time – was for Linux to adopt X11R6 and implement the X server (X +terminal) in software. This software X server would run on Linux +alongside the applications that used it.

+

Thus X applications on Linux worked exactly as they did on any Unix +system, but using the software X server rather than a graphics +terminal.
+This server, originally called XFree86, was a full implementation of the +relevant X11 protocols. It was perfectly capable of working with client +applications on Unix minicomputers, or applications running on different +machines, as it was with local applications. That is, the XFree86 X +server had the same ‘network transparency’ as proprietary X terminals of +the 90s. I’m stressing this point because it is emphatically +not a feature of Wayland. Wayland is fundamentally a protocol +for applications to interact with locally-connected displays.

+

It’s fun to speculate what would have happened if Linux had adopted +the ‘Windows way’ of managing a graphics display back in the 90s. Every +graphical Unix application would have had to be rewritten but, to some +extent, we’re doing that now for Wayland – we’re just thirty years +late.
+Probably XFree86 would never have been developed, much less Wayland.

+

Be that as it may, XFree86 eventually became X.org, after a bunch of +political shake-ups that aren’t particularly relevant, and so it +remains. In its early days, X.org mostly worked with hardware drivers +that were written specifically for it. There were drivers for video +adapters, naturally, but also keyboards, pointing devices, touch +screens, and so on. We usually had to write arcane configuration files +to select which drivers to use, and how to set them up. Later, a measure +of auto-configuration entered X.org, so it could handle many common +set-ups automatically. Still, the arcane configuration continues to +exist, for uncommon installations.

+

In the years after about 2010 there were two important changes in the +Linux ecosystem, which became crucial factors underlying the incentive +to develop Wayland.

+

First, some of the functionality that was formerly part of the X +server started to be replicated in other parts of Linux. Drivers for +graphics hardware, for example, started to move to the kernel. Widely +available libraries like libinput took over the detection and +integration of input devices. These changes were easily accommodated in +X.org, by writing new drivers for these new hardware interfaces. But the +old drivers never went away – they’re still in the code base, and still +have to be maintained. It’s unlikely that any new graphical +interface would need to use the same private device drivers that X.org +has and, indeed, Wayland generally does not.

+

The second important change was the widespread adoption of graphical +application frameworks like GTK and Qt. These frameworks worked with +X.org, but they also worked with Microsoft Windows and other platforms. +To enable this portability, the frameworks took over a lot of the +rendering work that used to be done by X.org. For example, X11 defines +protocols for displaying text in particular fonts, but GTK applications +typically do their own font rendering using a library like Cairo. So a +huge chunk of X.org rapidly became somewhat redundant. In fact, many +applications began to treat X.org as a kind of ‘super framebuffer’, +using extensions to X11R6 that allowed this mode of operation.

+

The complexity of X.org stems from its complicated driver +infrastructure, its ad hoc extensions, and the colossal feature +set of X11R6 itself. Yet it still requires a heap of supporting +software, if it is to be at all useful – particularly a window +manager. The screenshot below shows a couple of X applications +running with X.org, without any window manager. You’ll notice +that there are no window decorations, so there’s no way for the user to +manipulate the size of position of windows. Nor is there any way for the +user to switch active windows except with a mouse click.

+
+ + +
+

The job of manipulating windows on the user’s behalf falls to the +window manager. The window manager creates new, larger windows that +correspond to the applications’ windows, and then re-parents the +applications’ windows to be child windows of these larger windows. It +then then fills in the decorations – caption, buttons, etc. It’s the job +of the window manager to detect when the user has done something that +results in a window’s changing size or position; the application does +not do this, nor does X.org. So, with the simple, ancient TWM window +manager, and the same applications as before, we get this:

+
+ + +
+

Modern X window managers support ‘compositing’, using a specific +extension to X11R6. The window manager tells X.org not to render an +application’s graphics directly to the screen, but to some off-screen +buffer. The window manager then manipulates the applications’ buffers in +some way, before passing the modified results back to X.org for display. +This compositing operation provides support, for example, for window +transparency and other eye-candy.

+

This discussion about window managers isn’t a digression – window +management is one of the main differences between X11 and Wayland, as +we’ll see. It also illustrates another, more subtle problem: +security.

+

The X11 protocols define security at the user level, not at the +application level. Any application can manipulate any windows owned by +the same user. It’s precisely this fact that makes a window manager +possible – the window manager is just a client of X.org, with specific +responsibilities to other clients. But X11 came to prominence at a time +when the Internet was a less hostile place; we need to be a bit more +careful about security these days. As you might expect, Wayland takes a +different line on inter-window communication.

+

By about 2012 we were in a situation where X.org was stupendously +complex and feature-rich, but many of its features were only used by +legacy applications. That’s even more the case today. There were (and +are) multiple ways to interact with the same hardware in X.org, each of +which has an implementation that needs to be maintained. And features +that are only used by legacy applications have to continue to work, so +long as those applications remain in use.

+

There was, therefore, an incentive for a complete overhaul of the +whole X Window System; but there was no practical way to do this so long +as X.org was at its heart – X.org was just too complex, too enormous, +and too poorly understood.

+

In fact, many Linux maintainers felt that the whole, +network-transparent architecture of X11 was unnecessary in the world of +desktop computing. After all, many modern applications had been treating +X like a glorified framebuffer for years. Microsoft Windows worked +perfectly well without network transparency. So, rather than overhauling +X.org, perhaps it would be better to start from scratch, with a new kind +of architecture?

+

The Wayland architecture

+

We’ve seen that X.org provides a server process that implements the +X11 protocol. In almost all cases, X.org has to be combined with a +Window manager to be useful. Modern window managers went beyond the +original intention of X11, and performed their own composting +operations, transforming the output of X applications.

+

Wayland combines most of the graphics server, window manager, and +compositing functionality into a single Wayland compositor. The +rest it delegates to ordinary clients. Starting a Wayland session +amounts, in the end, to starting a compositor.

+

Proponents of Wayland often claim that it leads to simpler software +than was possible with X. But if a Wayland compositor combines so much +functionality from the X window system into one process, how can it be +simpler than X.org?

+

It’s possible because Wayland protocols are simpler than X11 +protocols, with a much smaller feature set. So the Wayland compositor +doesn’t have to do more than a fraction of what X.org can do. A +lot of legacy code, rarely used in modern application programming, is +eliminated. The Wayland compositor is simpler also because it doesn’t +have to implement all the legacy drivers that X.org does: in practice, a +compositor might support only the kernel’s display drivers (the Direct +Rendering Manager, DRM), and libinput, and that’s all.

+

Another way of looking at this is that Wayland is simpler because +Wayland clients are more complex. Wayland makes the client responsible +for a heap of functionality that was previously provided by the window +manager, as well as by X.org.

+

Wayland client applications communicate with the compositor primarily +using Unix sockets and shared memory. Messages that originate in the +client are called requests; those that originate in the +compositor are events. A typical request is to draw a memory +buffer on screen; examples of events include mouse clicks and +key-presses. Conceptually, this isn’t very different from X11 – what’s +different is the hugely reduced set of requests, compared to X11.

+

Because the compositor is simpler than an X server, there is no +single implementation – there is no ‘Wayland server’.

+

Compositors everywhere

+

In practice, X.org is the only viable X server for Linux. The same is +not true of Wayland compositors. Because the compositor is comparatively +simple, compared to X.org, there are many implementations already, and +probably there are more to come.

+

The reference implementation of a Wayland compositor is +Weston. When run in its most minimal form, a Weston display +looks like this:

+
+ + +
+

This display doesn’t look all that different from X.org with the old +TWM window manager that I showed earlier. There’s no separate window +manager, but you’ll see that there are window decorations that we can +use to move and size windows. The way to manage these window decorations +is one of the most contentious aspects of Wayland, which I’ll discuss +later.

+

Not only is there no such thing as a ‘Wayland server’, there’s no +such thing as a ‘Wayland driver’, either. Adding support for new +hardware to Wayland amounts to adding it to the compositor, or to some +existing driver infrastructure which the compositor understands, like +the Kernel DRM system. Clearly the latter approach is best, because it +doesn’t require changes to every compositor. Nonetheless, in practice +some hardware does require specific support in the compositor, +and this is an ongoing problem. Some compositors support some kinds of +hardware better than others do.

+

Because there’s no window manager, window management in the Wayland +world is a shared responsibility between the compositor and the client. +This means that if you want window management behaviour that is at all +unconventional, it’s not a matter of implementing a new window manager, +but implementing a whole new compositor. For example, the Matchbox +window manager is often used with X.org to provide a single-window user +interface for kiosk applications. Matchbox will show all applications in +full-screen mode, and all dialog boxes are modal.

+

Some Wayland compositors are flexible enough to be configured in +kiosk mode, but if you want a lightweight compositor that only +supports this mode – a Wayland equivalent of Matchbox – you’ll need a +specific compositor. One example is Cage; perhaps there are +others.

+

If it seems crazy to have to implement a whole new compositor to get +different window manager behaviour, perhaps relief is at hand. A +compositor framework called wlroots provides a C library that +can handle most of the fundamental needs of a compositor. wlroots is +associated with the Sway compositor, but it can be used +independently. A compositor based on wlroots can usually be configured +using the environment variables that wlroots uses, in addition to the +configuration provided by the compositor itself. This can be a little +irksome for users.

+

While many compositors are based on wlroots, some of the most +important are not. In particular Mutter, the compositor +currently used by the Gnome desktop, is not based on wlroots.

+

The Wayland protocol makes many compositor features optional. For +example, earlier I touched on the window decorations that could be seen +in the screenshot of the Weston compositor. Since there’s no window +manager, what is drawing those decorations? Well, it could be the +compositor, or it could be the client. The Wayland protocol provides +support for both, but compositor decoration is an optional feature. A +client can ask the compositor to handle window decorations but, if it +won’t, the client has to be prepared to do it.

+

This is one of many aspects of Wayland that require clients to work +harder than they did with X11.

+

Make those clients +work for their living

+

We’ve seen that a Wayland compositor combines the roles of display +server and a compositing window manager, but we haven’t considered how +clients actually interact with the Wayland compositor.

+

While X.org implements a huge range of features that allow clients to +draw shapes and write text to the display, Wayland really has only one. +Under Wayland, clients essentially exchange memory buffers containing +pixel data with the compositor. There’s no support in the compositor for +drawing shapes or text. To be fair, a client that uses 3D drawing APIs +derived from OpenGL might be able to use the EGL functionality built +into Wayland, so it’s not necessarily a case of direct pixel-pushing for +the client. Still, most clients are going to do a lot more rendering +than they needed to with X.

+

This might seem like a step back in functionality, compared to X11 +but, as I explained earlier, most GUI toolkits have been rendering their +own text and shapes for a while. There’s no doubt that this reduced +feature set makes the compositor a lot simpler, it it might not +make the clients more complex to write, depending on much use they make +of existing graphics frameworks.

+

In Wayland terminology, a region of pixels that can be drawn by the +client is called a surface. A screen window can be considered a +surface, but it isn’t the only thing that can – a cursor image, for +example, is also a surface. More on this point later. A surface is, in +effect, a miniature framebuffer. The compositor’s job, essentially, is +to merge the surfaces together onto a single display.

+

Clients talk Wayland protocol with the compositor using a Unix socket +– it’s not a network connection: network transparency is not a feature +of Wayland. The socket isn’t really used to pass surface data – that’s +the role of shared memory – but the socket protocol does specify the +location and properties of the memory buffer. Some compositor +implementations will share pixel data with a client using buffers in a +GPU device, rather than main memory. This might be a useful capability +for clients that do their rendering on a GPU, but compositors aren’t +required to support this feature.

+

Since not all compositors support compositor window decoration – +Gnome Mutter, notably, does not – clients have to be prepared to draw +their own decorations. Not only must the client draw the decorations, it +must respond to pointer events in the decoration area, and tell the +compositor to move, resize, or otherwise modify the window.

+

If clients have to draw window decorations, what stops every client +drawing its own window frame, buttons, etc? Well, nothing, as it turns +out.

+

For the application developer, this is a radical change from X11, +where everything related to window decorations was handled by the window +manager. Now, to be fair, X11 allows for applications to draw and handle +their own window decorations – these clients just told the window +manager to leave them alone. Most X applications don’t do this, however, +so it’s relatively easy to get the same window look-and-feel across a +range of applications. With Wayland, however, this consistency cannot be +guaranteed.

+

For an X developer, it’s difficult to see how this Wayland design +decision – forcing clients to be able to draw their own window +decorations – can be possibly be justified. I’m certainly not going to +attempt to justify it. Only the near-ubiquitous use of frameworks like +GTK and Qt make this situation remotely tolerable for the developer. The +frameworks will take care of the window decoration, either on their own +or using some general-purpose decoration library; but there’s still +going to be an inconsistent look-and-feel if applications aren’t all +built using the same framework. Providing some central place to make +configuration changes to window decoration (such as text caption sizes) +is not straightforward.

+

Similar extra work arises for the client in the handling of cursors. +With X11, the application provided a cursor image for a specific screen +region, and the X server drew it when the pointer was in the appropriate +place. With Wayland, applications are expected to draw their cursors +into a display surface. While this method is, presumably, more flexible, +it’s a lot of work for the application developer. Again, though, +application frameworks take care of a lot of the drudgery, so it’s not a +problem that the application developer has to tackle – unless he or she +isn’t using such a framework.

+

If you’re not using a graphics framework – and sometimes even if you +are – you’re potentially going to run into problems with compositor +compatibility. For example, wlcock intends to be a +native Wayland version of the traditional xclock. It uses +the Cairo library to render the clock face, rather that the 2D graphics +features of X11. If you run this utility using the Weston compositor, +you’ll get this error message:

+
ERROR: Wayland compositor does not support zwlr_layer_shell
+

The fact that wlclock doesn’t support compositors +without this capability is documented, but Weston is the reference +implementation for a Wayland compositor. Does that mean +wlclock is broken, and should find some way to work without +the missing capability, if it is not present? Probably.

+

But this is a clock, for Heaven’s sake. There could hardly +be a simpler graphical application. Yet it still demands capabilities +that are not present in the reference Wayland compositor.

+

Nobody actually uses Weston for day-to-day work. +wlclock works fine with Sway, for example. Certainly there +are X11R6 extensions that particular applications demand – but that’s +not a problem, as there is only one X11R6 implementation for Linux, so +application developers know exactly what they can expect from it. That’s +not true for Wayland.

+

In short, Wayland makes more demands on application developers than X +did. It’s going to be much harder to develop applications that don’t +rely on heavyweight frameworks like GTK.

+

XWayland

+

Since there’s little chance of all existing X.org applications being +ported to Wayland any time soon, there’s a compatibility server called +XWayland. This is actually a full X server, whose output is +to a Wayland compositor. So X applications will continue to use X11 +protocols, to this intermediate X server.

+

In practice, XWayland seems to work pretty well, considering it’s +inserting a proxy process between all client operations and the actual +display server. Setting it up is a bit fiddly, but users of mainstream +distributions will not usually have to deal with that.

+

Wayland and integrated +desktops

+

While there are simple Wayland compositors like Weston, in practice +almost everybody who is using Wayland uses it as part of an integrated +desktop environment. Gnome and KDE provide their own compositors (Mutter +and KWin respectively) that are tightly coupled to the rest of the +desktop.

+

Wayland and resources

+

Its supporters promote Wayland as less resource-intensive than X. +Certainly, a rudimentary Wayland compositor like Weston or Cage uses +less memory than X.org, and a lot less than X.org plus a modern window +manager. But nobody’s actually running Weston or Cage on a Linux +desktop. It’s difficult to compare the resource-efficiency of a modern +integrated desktop on Wayland or X.org, because most of the resources +aren’t used by the core components.

+

The same confusion applies to client applications. Like-for-like +comparison is difficult, for anything but the simplest applications. +weston-terminal is a rudimentary terminal emulator, broadly +equivalent to the traditional xterm. On my system +weston-terminal users about 14Mb RAM, xterm +about 6Mb. It would be wrong to assume that a Wayland client will +always need 2-3 times the RAM of an X client: in a substantial +application, most likely the basic user interface will only account for +a small part of the overall RAM usage.

+

The question which of X.org or Wayland is more resource-efficient, +therefore, is not easy to answer: probably, running a modern integrated +desktop and substantial applications, it won’t make any measurable +difference. For embedded and industrial applications I suspect that +Wayland will use fewer resources, because you’ll be using a lightweight +compositor. Gains in this area could easily be lost, however, if you +don’t choose, or write, your applications carefully: Wayland will +compel the use of graphics frameworks like GTK, in +circumstances in which X.org (in principle) did not. And if your design +calls for the use of XWayland, that’s an additional burden on resources. +How this will all work out in practice remains to be seen.

+

Plus ça change…

+

For an end user, much about Wayland is uncontroversial, at the end of +2024. Many Linux distributions – the most influential ones – are trying +to reduce their reliance on X. To some extent, they are succeeding. Most +end users adopt a specific integrated desktop – Gnome or KDE being the +most common – and use tools and libraries written specifically for those +desktops. These tools will have a consistent look-and-feel on Wayland, +and a consistent method of configuration. Most modern display hardware +works with Wayland, although different compositors have different levels +of compatibility with different hardware.

+

Things are harder for developers. If your application’s user +interface is provided entirely by a framework like GTK, you probably +don’t have all that much extra work to do, to support Wayland. But +moving an application that uses low-level X libraries, or non-mainstream +graphics toolkits, to Wayland is a wretched task – it amounts, more or +less, to rewriting it.

+

In practice, I suspect that nobody’s going to rewrite old, pre-GTK +applications using native Wayland APIs. If anybody actually wants a +native Wayland version of xterm, it’s going to be much +easier just to write it again using GTK or the like. Of course, there’s +no point, because such things already exist. If I wanted to use +xterm, it would be because I didn’t have an +integrated desktop and a heap of framework libraries, or I wanted to +minimize resources.

+

The most worrisome issue for developers, in my view, is the lack of +feature parity between different Wayland compositors. I explained earler +how something as simple as a clock application failed to run against +Weston. This brings to mind the notorious ‘browser wars’ of the 2010s. +At that time, a web developer would have to test applications against a +number of different web browsers, because all had different +capabilities. This was a serious productivity-killer. Over time, browser +technologies coalesced, and the situation isn’t anywhere near as bad +today.

+

Perhaps the same will happen with Wayland compositors. After all, if +there’s only one X.org, Linux could survive with only one Wayland. Right +now, there’s little chance of this happening, unless the maintainers of +KDE and Gnome are willing to work to common standards. It’s deja +vu, all over again.

+ +

+
+ + + + + + +