Wayland Will Never Be Ready For Every X11 User

After more than forty years, everyone knows that it’s time to retire the X Window System – X11 for short – on account of it being old and decrepit. Or at least that’s what the common narrative is, because if you dig into the chatter surrounding the ongoing transition there are some real issues that people have with the 16-year old spring chicken – called Wayland – that’s supposed to replace it.

Recently [Brodie Robertson] did some polling and soliciting commentary from the community, breaking down the results from overĀ 1,150 comments to the YouTube community post alone.

The issues range from the expected, such as applications that haven’t been ported yet from X11 to Wayland, to compatibility issues – such as failing drag and drop – when running X11 and Wayland applications side by side. Things get worse when support for older hardware, like GeForce GT610 and GT710 GPUs, and increased resource usage by Wayland are considered.

From there it continues with the lack of global hotkeys in Wayland, graphics tablet support issues, OBS not supporting embedded browser windows, Japanese and other foreign as well as onscreen keyboard support issues that are somehow worse than on X11, no support for overscanning monitors or multiple mouse cursors, no multi-monitor fullscreen option, regressions with accessibility, inability of applications to set their (previously saved) window position, no real automation alternative for xdotool, lacking BSD support and worse input latency with gaming.

Some users also simply say that they do not care about Wayland either way as it offers no new features they want. Finally [Brodie] raises the issue of the Wayland developers not simply following standards set by the Windows and MacOS desktops, something which among other issues has been a point of hotly debated contention for years.

Even if Wayland does end up succeeding X11, the one point that many people seem to agree on is that just because X11 is pretty terrible right now, this doesn’t automatically make Wayland the better option. Maybe in hindsight Mir was the better choice we had before it pivoted to Wayland.

Continue reading “Wayland Will Never Be Ready For Every X11 User”

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

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

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

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

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

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.