Raspberry Pi OS Now Using Wayland By Default (phoronix.com) 36
Phoronix's Michael Larabel reports: Over the past year we have seen Raspberry Pi working a lot on Wayland support for the Raspberry Pi OS desktop and using it on their latest Raspberry Pi models. With today's new Raspberry Pi OS update, Wayland is being used by default across all Raspberry Pi devices. The new Raspberry Pi OS update shipping today is using Wayland across all Raspberry Pi models. Labwc is also now the Wayland compositor of choice and those upgrading their existing Raspberry Pi OS installation will be prompted whether to switch to Labwc or keep using the prior Wayfire compositor. Raspberry Pi developers feel that the Labwc Wayland compositor offers the best experience on their single board computers. You can learn more about the update and download it via the RaspberryPi.com blog.
Further reading: Raspberry Pi Launches Its Own Branded SD Cards and SSDs - Plus SSD Kits
Further reading: Raspberry Pi Launches Its Own Branded SD Cards and SSDs - Plus SSD Kits
I hope it's improved (Score:2)
I tried the Wayland version of Raspberry Pi OS about six months ago and it sucked. Even just moving the mouse around consumed 40% of CPU resources.
Went back to the old version (Bookworm?) and things went back to normal.
Re: (Score:2)
X was designed in the 1980s. It's going to be more efficient than most things designed in the 2010s.
Re: (Score:3)
Silly desktop effects take fewer passes on Wayland than X11. But making every window into a GL/Vulkan context with two or three dedicated buffers is not appropriate for a resource constrained system.
Also, screwing around with hot config files to adjust display settings and rendering options is a huge step backwards from having X11's RandR protocols.
Wayland also took a step backwards with input methods editors, somehow doing a worse job than X11 at it. Almost would have been better to do nothing at all (whic
Re: (Score:2)
I have X driving four monitors... two at 1920x1080, one at 1920x1200 and one at 3200x1800 (scaled in software to 1600x900). I assume it uses GPU acceleration, but it's plenty fast.
This is obviously not on a Pi. It's on a very fast workstation with a pretty decent video card.
Re: (Score:2)
Things like twinview help. Where GL contexts can live on one GPU but access different display controllers. When I ran a 2x2 screen configuration I really only had to deal with two GPU contexts.
Try playing one video expanded to 4 screens at once in X11 (I'm assuming you're using Xinerama, obviously won't work if you aren't). That tends to side step the acceleration fast paths, and you'll start setting some heavy GPU usage. The same thing can be done in Wayland without leaving the acceleration path.
The Pi sho
Re:I hope it's improved (Score:5, Insightful)
I didn't think Wayland is very good.
I do agree with your point that just because X was from the 80s it just be more efficient. However... It's not from the 80s of home computers you are thinking of. Back when X was new, none of the high end machines were fast enough to push pixels on the CPU, so the entire design was around hardware acceleration.
X is all about opaque pixmaps which you hand off to the rendering system. It was designed from day 1 for acceleration. Now that's not to say that the model matches today's hardware well, but that's a different fish to fry. It's funny to hear GLX as hacked in. It arrived in 1994 with sgi, a scant 7 years after X was new, and we've now had it for 30.
Anyways Wayland shouldn't be worse, or fundamentally less efficient, but... Wayland is what you get when you ignore 30 years of experience and reckon you know best.
Re: (Score:2)
It's not from the 80s of home computers you are thinking of. Back when X was new, none of the high end machines were fast enough to push pixels on the CPU, so the entire design was around hardware acceleration.
Not true. We were pushing them on 68K without acceleration. Only in the SGI era was X11 seeing real improvements for acceleration. But it was also wrestling with weird framebuffer designs that vendors like Sun and HP were using on some machines. X11 quickly became about broad compatibility. The back end became much more flexible in the X11R4 era, with extensions to match what some of the vendors were already doing at the time.
X is all about opaque pixmaps which you hand off to the rendering system. It was designed from day 1 for acceleration.
They were designed for efficient BitBlt. And you can see that in how the bits are
Re: (Score:1)
Re: (Score:2)
Wayland can be more efficient (and is wildly more efficient than X). The resource issue on earlier models can be down to many things including how the underlying system works, and given that their "older models" are still actually their current models they likely have resolved the resource issue.
I'm sure you have profiling numbers to back that up, right?
Re: (Score:2)
That's not how burden of proof works.
thegarbz made the claim that "Wayland is wildly more efficient that X". That is a positive claim. That claim requires proof. None was provided.
phantomfive asked for data that backs up that claim.
It is not on phantomfive to disprove the claim.
Re: (Score:1)
I'm sure you have profiling numbers to back that up, right?
Yeah you can see them in a presentation by Wayland developers (former X developers) with the 1hour video subject to a Slashdot post almost a decade ago. The search box is in the top right. I'm not an expert and I don't profile shit, so I'll defer to the X developers (now Wayland developers) who actually know this topic intimately.
But leaving that aside, can you at least agree the premise of my post is correct, that old != efficient? Or will you be calling Windows 11 efficient in a few years time?
Re: (Score:1)
X of the 80s is barely even being used. Modern apps running on Qt or Gtk aren't rendering using X primitives, they're rendering the entire application through hardware acceleration into a surface or pixmap via Qt Quick or Cairo. Then an X extension attempts to composite this pixmap / surface with some other surfaces to make a desktop. X is the bottleneck all the way through since it is clueless to all this and introduces various unnecessary context switches and problems for the compositor. It also has vario
Re: (Score:2)
I have no idea what Raspberry Pi's issue was in its Wayland implementation in the past but I can well imagine that hardware acceleration wasn't being fully utilised for whatever reason in the past and now it is.
Yeah, you don't know.
And Wayland has less context switching and a more efficient protocol between client and display server so it should yield a far more responsive and memory efficient local desktop.
Did you profile it, or are you making things up?
Re: (Score:2, Interesting)
If you bothered to read the technical write up of Wayland you would know it has less context switching. You would also know issues inherent to X and why nobody, including the X maintainers saw any way to fix them. You would also know that Wayland is a protocol, not an implementation of a client / display server and there are a lot of things that could impact performance that have nothing to do with context switching. And I'm sorry for dare speculating a likely cause for RPi enabling Wayland now. If you're s
Re: (Score:2)
Don't be the latter.
Re: (Score:3)
2020 things like using a display server for application windows?
Or restarting the window manager without crashing all the clients?
Or accessing applications via ssh -X ?
Re: (Score:2)
Even 1980 things on 1980s computers were very often inefficient. X11 was not widely known for efficiency at the time, but it worked mostly because the screens of the day were small and you could easily use the CPU to render each pixel. There were bottlenecks but the amount of data through those bottlenecks was manageable. I even saw specific slowdowns on some operations where you could see windows being rendered. You could see distinct improvements just by changing compiler optimizations when building X11.
Re: (Score:2)
Re: (Score:2)
No, but if you've got video then there's a lot of pixels changing every frame.
Re: (Score:2)
Couldn't get rid of it quickly enough. I can't even understand why you have a VNC enabled by default. Elitist comment: if you can't do it remotely using the shell, you have no business doing it at all.
Re: (Score:2)
What a joke Wayland is if only because it's being pushed by someone/someorg with an agenda which doesn't sold water but distro's are believing the scam.
I remember way back when IDEs were multi-windows with separate debugger windows from the code/source window, separate step and program control window and on multi-display systems it was great and even on a single display system which had multi
A GUI on a Pi? (Score:2)
Why would you run a GUI on a Pi? Admittedly, I haven't tried the Pi 5, but I did try using a Pi 4 as a desktop machine just for kicks, and it wasn't great. Pretty slow, terrible YouTube playback. This is not what the Pi is meant for. Even the cheapest mini-PC will outperform a Pi as a desktop machine.
I have two Pi Zeros, an ASUS TInkerboard, a Pi 3 and three Pi 4s running various services for me. Only the Pi 3 even has a display and it's a custom thing I wrote to scroll weather and news in my living r
Re: (Score:3)
You run a GUI on a Pi if you are writing Pi-specific applications. Anything that uses the camera or the GPIO for example. A Pi 5 will run VS Code reasonably well, even through VNC. It is way better than a Pi 4.
Re: (Score:2)
TL;DR
Your post is literally almost as long as the parent's.
Re: (Score:2)
Why wouldn't you? Pis have literally had screens available for them since the very first one hit the market. There's countless reasons or projects which require a GUI or at the very least a window manager to run underneath and even the older Pis were very capable of that. Be that digital picture frames, interfaces for 3D printers, media players, arcade machines, or heck even the Pi I used as a basic NAS for a few years had a GUI that fired up X and displayed a window to show available disk space and network
Re: (Score:2)
Actually, it makes a lot of sense. Pis are used as controllers for CNC machines, for example. CNC machines make a lot of dust, and you don't want your expensive laptop to suck that in. A Pi with a touchscreen and a few buttons works fine as a controller.
There are enough machines that are controlled via a graphical environment, and Pis are suitable computers to make that possible.
Re: (Score:2)
LoB
Re: (Score:2)
Kodi runs well enough in 1080p on a pi4, did too on a pi3. The same holds for retropie.
The RPi goals are confusing to me (Score:3)
0) Dual 4K HDMI outs, on an SBC. Why?
1) They caution you on not expecting desktop performance, but offer desktop video. Uh, Why?
2) Single-lane PCI is great. But dual lane would make SSD Raid simpler.
3) GPIO really doesn't seem, to me, to be a feature that makes sense with the dual 4K HDMI...
4) You're thinking about now that I'm confused about including dual 4K HDMI outs on the Raspberry 5. Right you are.
6) At least they added a power button. Consistent with the desktop use. Not much with the embedded goals, maybe.
And yet, in all this, I have RPIs 3,4 and 5 running. And a Zero 2W and a Nano, all doing things from helpful to unnecessary.
Re: (Score:2)
LoB
Re: (Score:2)
Once you accepted systemd you lost a lot of arguments with the smart people.