Wayland

8 Articles

Raspberry Pi OS’s Wayland Transition Completed With Switch To Labwc

October 28, 2024 by 88 Comments

With the latest release of Raspberry Pi OS (formerly Raspbian) the end of the X Window System has become reality, completing a years-long transition period. Although this change between display servers is not something which should be readily apparent to the casual user, the change from the client-server-based X11 protocol to the monolithic Wayland protocol has a number of implications. A major change is that with the display server and window manager no longer being separate units, features such as network transparency (e.g. remote X-sessions) are no longer a native feature, but have to be implemented separately by e.g. the Wayland compositor. Continue reading “Raspberry Pi OS’s Wayland Transition Completed With Switch To Labwc” →

FLOSS Weekly Episode 798: Building The Rust Desktop With COSMIC

August 28, 2024 by No comments

This week Jonathan Bennett and Rob Campbell chat with Carl Richell about System 76, COSMIC, Wayland, Rust and more! What was the “last straw” that convinced System 76 to write their own desktop environment (DE)? What’s the story with smithay, and why did that jump start the whole process? Listen to find out!
Continue reading “FLOSS Weekly Episode 798: Building The Rust Desktop With COSMIC” →

FLOSS Weekly Episode 763: Fedora Fixes Everything

December 27, 2023 by 18 Comments

This week Jonathan Bennett and Dan Lynch talk once again with Neal Gompa of Fedora, CentOS, openSUSE and more. This time the focus is Fedora, with sprinklings of Immutable Linux, KDE 6, and the new Linux stack of Pipewire, Portals, and Wayland. Neal gives us a rundown of what exactly makes Fedora Atomic so interesting, and why you probably don’t want it running on your desktop. But in a computer lab, or on a public machine? Fedora Atomic might be exactly what you need.

Up next there’s Pipewire, the userspace sound server that replaces Pulseaudio and Jack. Should we think of Pipewire as Jack 3.0? And what’s the secret to getting really reliable low-latency performance for Pipewire in Fedora? It might not be what you expect.

There’s a popular rant online, that Wayland breaks everything. And for years, that’s been a relatively accurate statement, in that Wayland hasn’t been ready for prime-time. Fedora 40 has gone all in on the belief that Wayland’s time has come, with KDE and Gnome no longer having an X11 native option. It’s Wayland all the way. And as one that has run Rawhide, I can say that the future there is bright. Literally, if you have an HDR capable monitor.

Continue reading “FLOSS Weekly Episode 763: Fedora Fixes Everything” →

Debian Bookworm Comes To The Raspberry Pi, And Wayland Is Now Default

October 13, 2023 by 48 Comments

It must have been a busy week for the PR department at Raspberry Pi, with the launch of their latest single-board computer, the Pi 5. Alongside the new board comes something else, an updated Raspberry Pi OS version.

This is built from Debian 12 “Bookworm”, and supplants the previous “Bullseye” version. As well as the new OS base it comes with a pile of Pi-specific upgrades including an optimsied version of Mozilla Firefox. Probably most important is that henceforth (at least on 64-bit boards) its desktop will use the Wayland compositor rather than X11 to draw and manipulate windows. This is a development that has been in the works for a very long time — it must be almost a decade since the first Raspberry Pi blog entry about Wayland — so it’s welcome at last to see it.

The new tweaks as well as Wayland are supposed to deliver a much faster Pi experience, so we thought we’d break out the stopwatch and do some rough real-world tests. The bench 8GB Pi 4 here has a vanilla 64-bit Bullseye installed, so off we went to measure boot time, Chromium browser opening time, and Hackaday load time. It was time to download the new 64-bit Bookworm image and do the same. Have we just downloaded a power-up?

Both tests were done with an everyday boot, after the first-time OS set-up, and with all browser caches emptied. First up was a significant boost, with Bookworm booting in 37.14 seconds to Bullseye’s 53.5, but the Chromium opening was a little more disappointing. On Bullseye it took 7.15s, while Bookworm’s Chromium managed a more pedestrian 9.13s. The new Firefox takes only 7.95s to open. Both Chromium browsers load Hackaday in about 1.8s, while the new Firefox did the same job in a shade over 3s.

So allowing for our stopwatch reaction time and the ad-hoc nature of the test, this is a faster-booting OS, but the underlying hardware is still the limiting factor. We’re disappointed to see that there’s no update for the x86 version of the Raspberry Pi Desktop, and we hope they’ll be able to rectify this in the future.

A Raspberry Pi As An Offboard Display Adapter

May 9, 2022 by 6 Comments

The humble USB-C port has brought us so many advantages over its USB ancestors, one of which is as a handy display output for laptops. Simply add an inexpensive adapter and you can hook up everything from a mobile phone upwards to an HDMI display or projector. There’s a snag though, merely having USB-C is not enough as the device has to support the display feature. It’s a problem [Gunnar Wolf] had to face with a Lenovo ARM laptop, and his solution is unexpected. Instead of an adapter, he’s used a Raspberry Pi 3 and some software tricks.

The obvious route to an off-board Pi mirroring onboard video is to use VNC, which he tried but found wanting due to lagginess. As a user of the Wayland compositor he found he could instead use wf-recorder and send its output to a stream, and thus capture his screen in a way that the Pi could read over the network. It’s not quite as convenient a solution as a pure-hardware adapter, but at least it allowed him to share the screen.

It’s surprising how often we find projects needing to mirror the display of a computer using what hardware is to hand, at least this one is more elegant than some others.

Firefox logo displayed on screen

Firefox Brings The Fire: Shifting From GLX To EGL

November 23, 2021 by 55 Comments

You may (or may not) have heard that Firefox is moving from GLX to EGL for the Linux graphics stack. It’s an indicator of which way the tides are moving in the software world. Let’s look at what it means, why it matters, and why it’s cool.

A graphics stack is a complex system with many layers. But on Linux, there needs to be an interface between something like OpenGL and a windowing system like X11. X11 provides a fundamental framework for drawing and moving windows around a display, capturing user input, and determining focus, but little else. An X11 server is just a program that manages all the windows (clients). Each window in X11 is considered a client. A client connects to the server over a Unix process socket or the internet.

OpenGL focuses on what to draw within the confines of the screen space given by the window system. GLX (which stands for OpenGL Extension to the X window system) was originally developed by Silicon Graphics. It has changed over the years, gaining hardware acceleration support and DRI (Direct Rendering Interface). DRI is a way for OpenGL to talk directly to the graphical hardware if the server and the client are on the same computer. At its core, GLX provides OpenGL functions to X11, adds to the X protocol by allowing 3d rendering commands to be sent, and an extension that reads rendering commands and passes them to OpenGL.

EGL (Embedded-System Graphics Library) is a successor of GLX, but it started with a different environment in mind. Initially, the focus was embedded systems, and devices such as Android, Raspberry Pi, and Blackberry heavily lean on EGL for their graphical needs. Finally, however, Wayland decided to use EGL as GLX brought in X11 dependencies, and EGL offers closer access to hardware.

When Martin Stránský initially added Wayland support to Firefox, he used EGL instead of GLX. Additionally, the Wayland implementation had zero-copy GPU buffer sharing via DMABUF (a Linux kernel subsystem for sharing buffers). Unfortunately, Firefox couldn’t turn on this improved WebGL’s performance for X11 (it existed but was never stable enough). Nevertheless, features kept coming making Wayland (and consequently EGL) a more first-class citizen. Now EGL will be enabled by default in Firefox 94+ with Mesa 21+ drivers (Mesa is an implementation of OpenGL, Vulkan, and other specifications that translate commands into instructions the GPU can understand).

Continue reading “Firefox Brings The Fire: Shifting From GLX To EGL” →