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.

For Raspberry Pi the transition to Wayland was based on the perceived efficiency and security benefits of the monolithic architecture, with the 2021 release of Raspbian (based on Debian Bullseye) testing the waters using the hybrid X11 window manager/Wayland compositor Mutter. This allowed for switching between X11 and Wayland without committing. In 2023 Mutter was replaced with the Wayfire compositor with Wayland becoming the default on Raspberry Pi 4 and 5 platforms. Along the way it was found that the Wayfire project wasn’t developing in a way that would benefit Raspberry Pi OS, which led to what should now be the final Wayland compositor in the form of Labwc.

One advantage of Labwc is that it is more lightweight than Wayfire and Raspberry Pi has judged that this means that it should be the default across all Raspberry Pi systems. Compatibility with X11-based software is maintained with the XWayland library, so that users should ideally not notice any difference after switching to Labwc even on lower-end boards. Unless you’re one one of those people who use features such as (remote) X-sessions, nothing should feel markedly different.

In addition to this big change, the new Raspberry Pi OS release also improves touch screen support with the integrated Squeekboard virtual keyboard popping up when a touch screen is detected. Finally, the remote access Raspberry Pi Connect feature sees a few tweaks, which is the feature that effectively replaces remote X-sessions. Considering how glacially slow X desktop sessions can be, this is something which can be considered an improvement, but it would be nice if there was an alternative that didn’t rely on Raspberry Pi-provided services to work.

75 thoughts on “Raspberry Pi OS’s Wayland Transition Completed With Switch To Labwc

  1. Urgh, this is just exhausting at this point. I guess I understand the need to switch away from X, but at least for me, the real change is that it’s really hard to find out how to do anything anymore. One of my projects involved auto-starting a few apps on a RPi, and I thought “great, an opportunity to learn how to use wayland”. But the thing is now if I search for how to do that all I get is a decade of great posts about how to do it in X, and almost nothing that’s relevant to wayland. And now I’ve just tried a search for how I might autostart apps in Labwc, and I’m honestly not sure if it’s even possible.

    I’ll be honest that I don’t really understand what X (or wayland, or wayfire, or labwc) really is and how it really works, but it feels like, for people in my position there really isn’t a good guide to understand the basics. I think the documentation (for wayfire at least) is pretty sparse, and in the absence of a decade of forum posts, blogs, hacks, stackoverflows, and everything else it just feels like such a struggle to do even the simplest things with a raspberry pi. Anyway, that’s just an opinion, and I’m not sure what solution there would, if any

    1. Since raspi is systemd based, start them using systemd services. Basically you write a service description file in /lib/systemd/system/mylittle.service, and enable it with “systemctl enable –now mylittle”

      1. That does not work with GUI applications, of course. Those can be autostarted with X-based DEs using XDG (Freedesktop standard) autostart files in /etc/xdg/autostart and the user-specific version. Under Wayfire you had to configure a different file for this, and with Labwc it’s different again, of course.

    2. biased and unhelpful comment follows

      Using a pi for gui applications is the wrong tool for the job. If you need either the smallest footprint or power usage, pis are great, otherwise x86 is winning outright.
      I’m sure the documentation / community understanding of how to do what you need in mainline x86 Debian or Ubuntu is easy to access.

      1. Raspis aren’t the best tool for low power consumption. My notebook uses about 2-3W writing this comment. I never got a raspi 4 down that low. I don’t own an raspi 5 so I can report on this. And my CPU is much faster, so when I need compute power it is available.

  2. I use and love the network transparency of X11 and the client server model. I guess that means it’s time to ditch all things Raspberry Pi. Wayland also breaks things like Xdo and easily scriptable and cli control of gui elements.

    1. doesn’t it get tiring? the constant bitching I mean. “this thing changed one thing I don’t like . therefore, I must discard all about it. that’ll surely teach them”.

      it’s open source. you’re free to modify it. you’re free to NOT use the default they provide, and use an alternative that suits your taste.

        1. That is a rather strange argument. So we are going to throw out Python in 7 years because it will be 40 years old then too?

          The architecture of X11 is more tinker friendly. It is pretty easy to build your own window manager in very few lines of code for instance.

          In general it seems that Linux is heading in the direction of what is good for corporations instead of makers/tinkerers.

          1. It is pretty easy to build your own window manager in very few lines of code for instance.

            Because it’s sitting on top of a pedestal that is only still standing due to the heroic effort of a very few people, and even they won’t be around for very much longer. You move people to a new ship while the existing one is still afloat, not after it’s sunk and everyone has drowned.

            Linux is heading in the direction of what is good for corporations instead of makers/tinkerers.

            The vast majority of Linux developers have either been directly funded by “corporations”, or they have well-paying jobs that leave them enough spare time to do it. It’s been like that for almost the entire lifetime of the Linux kernel. You might get it for free, but only because someone else is paying for it.

            Nobody is the sole arbiter of what “corporations” and “makers” want, certainly not you or I, and just because people make decisions that slightly inconvenience you specifically doesn’t mean that they’re somehow betraying this noble group you claim to be a part of.

        2. Age is not a criterium. You could argue the other way around, that if a package sets the standard for 40+ years, it already proves it can stand the test of time.
          As long as articles like this one don’t get any further than “the user shouldn’t notice a difference, but feature so-and-so will be missing”, there’s no reason to switch. Switch when it BENEFITS the user!

          1. Won’t hear me saying Windows is bad. I think my last stroke of that silly evangelism was 35 years or something, when I had an Amiga and the Atari ST was bad. After that I grew out of it.

          2. And Linux is based on Unix which is much, much older. Windows is the new fangled thing that was supposed to make Unix obsolete. I remember when Windows (NT) was new in the 90’s and they said it doesn’t need remote sessions or multiple simultaneous users like Unix since computers are so cheap everyone has one on their desktop. Funny thing that Windows supports both, now. So, yeah, age definitely isn’t a problem.

          1. “cat” is the bestest, real programmers never make mistakes and never need to edit their code!

            cat > hello_world.c
            #include<stdio.h>

            void main(int argc, char *argv[]){printf(“hello world!\n”);}^D`

            And it is the real reason everyone loves cats!

      1. it’s open source. you’re free to modify it

        Free to modify it as in speech, but not as in beer. “It’s open source” doesn’t mean you can flick a hidden config setting and get the behaviour you want. Sure you can make a small change to a small project and – assuming it actually compiles when you downloaded the source – you might get the solution you need for only a few hours of time (=$$).

        But making a substantial change to the OS is going to require substantial investment of time to understand what needs changing and to make it all work – assuming on a larger project that it’s even feasible for a single person to keep up with it. That’s hundreds to thousands of dollars of time invested, and you don’t know you’ll get the solution you want.

        And then, each time there’s an update, you have to re-patch it, which is not necessarily as simple as reapplying a diff. But even if it is, there’s certainly no auto-update, so you’re going to have to invest constant ongoing work to keep on top of security patches.

        1. “It’s open source” doesn’t mean you can flick a hidden config setting and get the behaviour you want”
          In the kernel it does, that is latterly what so many do when they rebuild the kernel. As for putting X11 back, so many options to do that, as simple as flicking a switch. On top of that these days with yocto / build root it’s even as simple a pulling some repo’s change some configs and you will have your own dream distro built by you built for you.

        2. “doesn’t mean you can flick a hidden config setting and get the behaviour you want”

          Only because that setting isn’t hidden. Yes, you can literally change one setting and the system will reconfigure to be identical to how it was previously.
          Not only is there a menu on install to pick your DE/WE, you can also do this after-the-fact on a running system.

        3. For me you’ve pretty much described why developers want to change to wayland. X is burdened with a lot of stuff that’s no longer relevant and it’s hard (or impossible) to add modern features at the appropriate level.

      2. it’s not open source. it’s raspberry pi. the graphics drivers are all deeply integrated with the firmware, which is closed source. it’s a real gosh darn nightmare, imo. for example, if i wanted to use the new version of raspios that uses wayland, i would have to give up all of the software i wrote based on the old firmware…because they broke all the APIs.

        it’s vaguely possible to hack it but it’s not any easier than it is with closed source windows. it’s not open source.

        1. XWayland is the API translation layer that it ships with to err not “give up all of the software” written for X11. Unless I’m missing something, I don’t see how the graphics firmware comes into it? (Which I agree with, it is annoying they are closed source binary blobs, but that’s not changed, and has got very little to do with Wayland/X11 unless you are writing wayland/x11?).

          1. it just means you have a very limited capacity to mix and match or modify components because whatever you wind up with has to work with the closed source firmware. if you take advantage of the open source nature of some parts of the userland, you will still be bitten when the underlying firmware changes. you will have to chose between your hacks and whatever valuable updates raspberry has given you. it is generally possible to modify it, like hjf says. but if you do modify it, you have to contend with a zillion interlinked decisions all downstream of an undocumented, closed, and constantly-changing firmware.

            on the pc, there are closed components but they are abstracted away to where it doesn’t hardly affect the open source components. but on raspi, the ‘open’ userland is a carefully-balanced hack closely integrated with the firmware. it is slowly getting better, but even that process of improvement is painful in a closed source kind of way.

          2. oh sorry i misunderstood your question! the software i would have to give up is written to use the firmware, not to use X11. the firmware has changed to a better interface than the interface they used in 2020 when i wrote my software that uses it. but the change means throwing away all of my work. and because the firmware is closed and undocumented and tightly-integrated, i can’t mix-and-match.

            in order to install wayland, i have to upgrade the firmware and give up my work. in order to keep my work, i have to use the 16bpp-only X11 they were distributing in 2020.

            if i did decide to throw away my work, and upgrade raspios, and use wayland, and configure wayland how i want it to be configured…i would be in the same position in 2 years. they would upgrade the firmware again, and change the supported display server again, and those customizations would fail then too. but the challenge i face today is because i used an obsoleted firmware interface

        2. This is such bs. There isn’t a graphic card nowdays for running normal desktop environments you can buy and it isn’t running its own proprietary firmware!

          Oh, you may find a decades old one but guess what? The hardware is not opensource anyway so it is not opensource by your standard!

          Oh but there is a truly opensource design somewhare…. which you can even build using opensource Yosys toolchain and run on your totally PROPRIETARY FPGA.

          1. yeah but on the PC i benefit from the open source components. i have used xfree86 or xorg for almost 30 years, and i have even hacked its source on occasion and found that to be valuable (for example, i am using a hacked evdev input driver that i have carried with me through 3 laptops now). the closed source components are wrapped in stable interfaces.

            on raspi, the closed source component keeps changing its interface and everything on top of it moves in sync to it. i can hack things but my hack will stop working in a year or two when they replace the entire stack that i had been depending on. upgrades are all-or-nothing because the userland is tightly integrated to the closed firmware. if you want to use a specific X server or wayland display server, you are locked to a specific obsolete version of the firmware.

    2. Wayland clients can be executed remotely quite trivially, so this is a nothing-burger.

      And this isn’t Windows, almost nobody needs cli control of gui elements, even if they think they do.

        1. I mean purely in the sense that practically anything you could do in a GUI in linux has a first-class CLI equivalent.

          There’s lots of GUI-only Windows apps, though, and a lot of people end up using AutoHotkey or AutoIT or other tools to automate actions on them.

          1. I’ve been slowly getting more comfortable with Linux over the last 2ish years, and I have absolutely no idea what you are talking about…

            90% or more of the nitty gritty stuff either has no gui control, has a jank 3rd party gui last updated 7 years ago, has a learning curve bigger than the GUI tool AND scripting that tool, or is missing ONE critical thing you need and forces out to use the GUI for at least that step.

        1. Don’t be disingenuous.

          It’s trivial to show that lots of people use some sort of windowing system be it X or Wayland or MacOS or Windows.

          Please, give me some obvious examples of where people would need to automate clicking a GUI button in an X or Wayland app where there isn’t a better and easier method. I’ll wait.

          1. Group A has reasons to want to update, and dismisses Group B’s reluctance because A doesn’t care about the features B constantly uses.

            Group B dismisses Group A’s desire to change, because the current system works for them, and the new system will require them starting from scratch again to get anything done.

            Buth sides have valid complaints.

            Don’t act like one side or the other is simply right.

        2. Everyone who wants a GUI. At all.

          Modern hardware doesn’t really work with X and X’s expectations about how hardware works map BADLY to modern hardware. On the M1 GPU it’s flat out impossible to make X11 work properly. It only works at all on nvidia and AMD because they both spend a lot of time hacking up their DDX drivers. Intel just flat out doesn’t give a shit anymore and as a result X11 is flat out broken on a lot of their older hardware.

          In the very near future it’s going to just be straight-up impossible to run X11 on modern hardware.

          Microsoft and apple have both moved on to more modern, better ways to render a desktop. It’s time the unix market did too. That’s why everyone who maintained xorg dropped it like a hot potato back in ~2015 and has been working full time on wayland ever since.

      1. i keep hearing this and i am ignorant about whether it’s true yet? i hope someone can clue me in?

        what i like about X11 remote execution is that it is thoughtless. i don’t have to anticipate that i will need it, i just am in an ssh session and i realize i’d like to view an image…i don’t have to start vnc, or scp over the image and view it locally, or put it in public_html or whatever. i can just run ‘xloadimage foo.png’ and X11 just magically works.

        obviously, i hate the X11 slowness! a lot of round trip overhead. so if i know i am actually going to be doing work with some remote program, i have a script that starts up a headless X11 vnc server and connects to it on my laptop. and then everything i run under that is relatively fast.

        so i know the overhead of starting up a vnc session is really pretty minimal…but i still like that i don’t have to for one-off impromptu tasks. i don’t have to anticipate that need.

        my impression of wayland is that there are options but whenever i put a toe in, it seems like there are too many decisions to make, and each decision ties you to a display server which will surely become abandonware soon (like in this article, i guess). there’s no default path for remote execution, and the diversity of paths provides plenty of features but no stability over time??

        in practice, does that matter? anyone have experience using wayland over a few years want to opine? do you have an easy time meeting your needs with a new display server or can you use the same one for years or what? do you have to periodically replace your whole userland of display clients or is there some steadiness over time?

    3. @UT
      That is a radical move but does it solve anything? I mean you would have to find other board with a X11 based distro hoping it will be equally mature to RPI and it’s OS. Why not just change operating system? I think Slackware still does that.

    4. Fun fact: X isn’t network transparent either and hasn’t been for 30 years. Everyone (and I mean EVERYONE) is dependant on extensions (shared memory and DRI2) which are absolutely not network transparent.

      See: https://youtu.be/RIctzAQOe44?t=1115

      X11 is network capable but saying that it’s the same over the network as on the same machine is total nonsense. It’s flatly false.

      And Wayland is network capable too now! It’s called Waypipe. https://gitlab.freedesktop.org/mstoeckl/waypipe

  3. Considering how glacially slow X desktop sessions can be, […]

    Dear Maya,

    After reading two of your recent texts here I’d like to kindly ask you to be a bit more carful with words you choose. Neither ZFS is an “afterthought” in Linux nor local X sessions are “glacially” slow (remote are, sometimes). If you do not have numbers to support such claims, try as hard as you can avoiding them.

    Thank you in advance,
    s

    1. Yeah that remark surprised me as well. “Glacially slow” is not my experience, and making such a subjective claim in a news item is bad journalism. Keep your opinions out of it. Want to give your opinion? Write a separate review or column or whatever.

    2. Agreed. “Glacially slow” is not my experience, even when on a remote session. This is just bad journalism. Keep your subjective comments out of news items. Want to give your opinion? Write a review or a column or something. News articles should be factual and objective.

    3. You say that as if you’ve never seen a remote X-session draw widgets slow enough that you can fetch a coffee before it’s done rendering a window refresh. Across a LAN it’s generally fine, and I have set up X-terminals in the past with no complaints, but remote X-sessions are a known pain point.

      Maybe my words are in fact backed by credible evidence. Something for you to consider.

      1. But you didn’t and haven’t cited any credible evidence, only replied to a comment with a personal anecdote. Measured and documented benchmark and statistics is credible evidence and there isn’t any to back up that claim in the article.

        1. Why would I need to cite evidence for something that has been common knowledge since the 1980s? Even in this comment section you can find others who corroborate it, but feel free to do some googling yourself if you feel a quaint urge to defend X11 for something that’s simply a feature due to how the protocol works.

      2. My limited experience with X11 remoting is that the experience is fantastic, even over a thin straw, if you’re only using the really simple (“ugly”) clients that are 1bpp (or almost) and are just drawing text and lines. And have enough memory for backing store. Absolutely no bitmaps, which is why almost all modern X11 (but also RDP and VNC, even over a high-bandwidth high-latency pipe) forwarding is painful.

        The early 68k-based NCD X terms were just slow due to the 68k; the later MIPS-based ones were rather pleasant.

    1. There’s nothing X can do that Wayland can’t, you just sometimes need different tools to do it, e.g. wayvnc or KRdp. Or just use Raspberry Pi Connect which the article already mentions.

      1. Because Wayland is SOOOO much more efficient than X it only runs on rPi 4 and 5 and anything before those has to get a reduced feature version of Wayland. What’s not to like about that steaming pile and who is pushing this since it sounds like something Microsoft would be wanting. ie a worst Linux experience.

        1. Old hardware getting less active development is pretty normal in all sectors. Be glad that it’s Linux and receives any updates at all, 12 year old commercial offerings rarely do.

  4. Pardon my ignorance, but aren’t GUIs just overlays to the CLI? All GUIs upon close inspection are decorative. You can buy a pre-decorated Christmas tree or a Christmas tree and boxes of ornaments and lights. A person can go to a field and chop down a tree and hand make ornaments and strings of lights. Others can blow glass, smelt metal, make paper, bake cookies …
    From each according to their abilities, to each according to their wealth.
    HaD gives me a sampler of all these activities – though dear HaD writers – you have come up short in the cookie recipe department this year.

    1. So what? Code doesn’t go ‘bad’ just because. That is why it trusted, stable. It works. I have code that I’ve not changed in many years (24×7 Scada application) and it just keeps working….

      1. It’ll stop building though. Linux is pretty stable but it’s a moving target, the kernel is changing, its libraries are changing. Your scada application is not a good comparison.

  5. I was disgusted to read about how inefficient and antiquated the X Window system was because it was built of 2 parts(client / server) and network protocol based and how great Wayland is because it is integrated to then hear Wayland is so inefficient it runs so poorly on anything less than a Raspberry Pi 4. Why is it still moving forward when one of its primary purposes, to be more efficient, has been proven wrong?

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.