gamescope VS awesome-wlroots

I think your information is quite outdated. The HWC overlay planes are heavily used, you can see this trivially just doing a 'dumpsys SurfaceFlinger' or grabbing a systrace/perfetto trace. When it falls back to GPU composition it's very obvious as there's a significant hit to latency and more GPU contention.

The overlay capabilities of the modern Snapdragons are also quite absurd. They support like upwards of a dozen overlays now and even have FP16 extended sRGB support. Some HWCs (like the one in the steam deck) even have per plane 3D LUTs for HDR tone mapping (ex https://github.com/ValveSoftware/gamescope/blob/master/src/d... )

The composition is bandwidth heavy of course, but for static scenes there's a cache after the HWC in the form of panel self refresh.

One of the unfortunate things about Wayland is every compositor will have its own quality of implementation affecting things like latency.

With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC.

If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department.

[0]: https://github.com/ValveSoftware/gamescope

Use gamescope.

While streaming from the Deck to another device (phone with Steam Link app or another PC running steam), taking a screenshot on the Deck (hold the steam or ... button, and press R1) crashes the session (https://github.com/ValveSoftware/gamescope/issues/961). This one also impacts Decky Recorder. If you're recording the screen or have replay mode on and take a screenshot, you'll have a crash.

Mangohud (GOverlay), libstrangle, gamescope. Pick your poison.

Hey folks. I've got a 11900H motherboard and use the iGPU and stock Intel graphics drivers that I keep current. Even at baseline (so without overclocking of any kind, with good Corsair memory sticks configured without XMP and regardless of voltage), I would be able to use Windows 11 and the CMD or Terminal programs without issue but after some time they would be corrupt and unreadable. The fix was in Terminal, go into Settings, then Render, and turn on Software Rendering. I hope this helps someone else. FYI the corruption was very much like other Intel UHD graphics samples reported in this link: https://github.com/ValveSoftware/gamescope/issues/356

If you are scripting-heavy user, I recommend trying out one of WMs based on wlroots (or implementing its custom protocols). Core Wayland protocols are designed with security in mind, which doesn't necessarily let you have all the automation fun. wlroots protocols bring back most of X11 capabilities at the cost of having similar security model.

https://github.com/solarkraft/awesome-wlroots is a pretty nice list of various CLI utils you can use. Sadly I don't think anyone aimed to 1:1 replicate APIs of xdotool etc, so you will need to change the syntax in your scripts a bit.

An incomplete list of compositors (they forgot hyprland):

https://github.com/solarkraft/awesome-wlroots#compositors

Among non-tiling ones are: hopalong, labwc, laikawm, tinybox, waybox, wayfire.

This appears to be an attempt at trolling or bait (“Drew Default”) but I’ll bite.

> Wayland ostensibly supports several dozen extensions, but only the GNOME-blessed extensions can be reasonably expected to work.

Instead of actual protocol extensions it seems like the author is talking about desktop tools. “only the GNOME-blessed extensions can be reasonably expected to work” oh GNOME and nowhere else, because GNOME has a “loose relationship” with standards. Meanwhile the rest of the ecosystem is unifying behind wlroots, which coincidentally I have made a small list of tools for that cover most needs: https://github.com/solarkraft/awesome-wlroots

> I can assure you that it’s a nightmare. Creating a new compositor would be a hellish experience. Ask any distribution packager who works with Wayland to share their horror stories — they have many.

Distribution packagers try to make compositors? Maybe they should take a look at wlroots.

> Even on the supported platforms it comes with a substantial burden on build requirements, calling for 10× to 100× or more RAM, CPU time, and power usage.

Obviously not. Some sessions on GPU acceleration being available nowadays, but that’s not a new development. The GNOME Wayland session has been demonstrated to be faster than the X session (many years ago on a Raspberry Pi).

> Novel hardware which addresses issues like microcode and open hardware, like POWER9 and RISC-V, are also suffering under Wayland’s mainstream-or-bust regime.

Why? What does “mainstream-or-bust”? Probably not the protocol maintainers’ tendency to compromise on things to make Wayland not appealing to average users (ha).

> Anyone left behind is forced to use the legacy Xorg codebase you’ve abandoned, which is much worse for their security than the hypothetical bugs you’re trying to save them from.

Xorg, by design and historical growth, is insecure. That said security fixes will of course continue to be shipped (I don’t say this with any internal knowledge of Xorg maintainable, only trust in the FOSS ecosystem). Of course, the user base is still huge.

> Rewriting your code in Wayland is always going to introduce new bugs, including security bugs, that wouldn’t be there if you just maintained the Xorg code. Maybe there are undiscovered bugs lurking in your Xorg codebase, but as your codebase ages under continuous maintenance, that number will only shrink.

Xorg is insecure. Not because of bugs, but because of features people rely on.

> Those of us who work with such systems, we feel like the Wayland community has put its thumbs into its collective ears, sung “la la la” to our problems, and proceeded to stomp all over the software ecosystem like a toddler playing “Godzilla” with their Lego, all the while yelling at us old fogies for being old and fogey.

I agree. I consider ”Out of scope” to be the unofficial Wayland motto.

The summary at the end is a beautiful soup of contradictions.

> Slow down the protocol

It’s already fairly slow.

> write a specification

That’s what a protocol is, isn’t it?

> focus on improving your protocol extensions

By that do you mean adding more? I thought the protocol was developing too quickly?

> support more Xorg programs

The charitable interpretation is that it means “support more Xorg use cases”, which is completely valid. The way it’s said would also allow for the interpretation that the author hasn’t understood what Wayland is and wants X APIs added.

> work on performance, stability, and accessibility

The protocol allows for very high performance. If individual compositors are inefficient, please talk to their maintainers. This isn’t an issue with Wayland in general. Same deal with stability. The compositor I use (wayfire) is super stable. Unfortunately I can’t comment much on accessibility other than that I know that Linux has historically been pretty bad in this area.

> Invest more in third-party implementations like wlroots.

With it defining the third compositor type besides KDE and GNOME I think wlroots is seeing an healthy amount of investment. What’s going too slowly for my taste is the standardization and adoption of wlroots protocols by other compositors (will GNOME ever care about what other people are doing? Will they stay incompatible forever?).

> Your ecosystem has real problems that affect real people. It’s time to stop ignoring them.

I completely agree. The “out of scope” meme may have been holding Wayland back. We need much more standardization, akin to the XDG standards. There’s still a lot to do.

wlrobs has issues for me with 2 screens of different densities. With xdg-desktop-portal-wlr the Pipewire route will work as well.

My favorite way to record on wlroots compositors is wf-recorder, which seems to be lighter on resources than the others.

There's also a fork of SimpleScreenRecorder (with similar issues, unfortunately).

Here's an overview of screencasting tools for wlroots based compositors like Sway and Wayfire: https://github.com/solarkraft/awesome-wlroots#screencasting

It's true, it's going to drag on for years. But Wayland is creeping into the mainstream. It has been the default on Gnome for a good while and Gnome Wayland is going to be the default in Ubuntu's new release. KDE is a bit behind but also on it, promising "production level quality" until the end of this year. At the same time a new class of compositors without any X heritage is emerging around the wlroots library.