The DEs practically everyone is using - minus Cinnamon, for now - have great Wayland support and have Wayland as the default session. Other smaller DEs and WMs have it on their roadmap.
Gamescope is a traditional normal compositor like Compiz or Picom, it is a “micro-compositor” in the sense that it is specifically targeted at gaming and full-screen applications to run in an isolated sandbox desktop session with a more suitable implementation of V-sync and native FSR and doesn’t necessarily implement things expected of a standard compositor like Compiz or Compton, which really are tailored more towards supporting interactions between various elements inside a WM, e.g. like transparency.
Normally the chain goes like this: Xorg (a display server) -> DisplayManager (more accurately described as a login manager like SDDM) -> Compositor <-> WindowManager.
A “Wayland compositor” is a semi-related partially overlapping concept with “Compositor”.
Because Wayland is an entirely different protocol that wasn’t made over 20 years ago, the separation between Window managers, display servers and compositors doesn’t apply in the same way, a “Wayland Compositor” incorporates some features of both a traditional WM and a traditional compositor, like if i3 had its own Compiz. Additionally these will also incorporate some features that were previously handled by Xorg or a display server.
You can probably guess at why this is if you recall one of the biggest earlier limitations of Wayland that have severely hampered it’s adoption and compatibility with various software, like Guake, for instance, and led to development of alternatives in lieu of ports :)
Kwin (as in the WM bundled with Plasma/KDE) under Wayland acts as a “Wayland Compositor” for instance, but under Xorg it’s just both a Compositor and a Window Manager.
As such, Gamescope isn’t a “Wayland compositor” at all, in fact running it in both gaming mode and nested mode runs an X server (Xwayland).
It’s also worth noting that Gamescope doesn’t even support Wayland hosts by default since it relies on Xorg stuff to do some of the magic, if you play with the resolution and display stuff in the launch parameters from terminal in nested mode (such as on the deck in desktop mode) and look at the log/debug/error output it should become fairly obvious why this is the case as well.
Gamescope does not support Wayland clients by default. To enable support for Wayland clients, add the --expose-wayland flag to Gamescope’s parameters.
WRT the Steam Deck, in gaming mode it actually runs an X server (Xwayland, a wayland -> X compatibility layer for compositors), then Gamescope within with MangoApp for the performance stats.
SSH while it’s in game mode and see for yourself.
TL;DR: Gamescope uses Xwayland (an X server), but it’s not a “Wayland Compositor”, it’s just a compositor.
But you can also run Gamescope steam big picture in a Wayland session if you wish from your DM of choice if the arch wiki is to be believed. I’m not sure if this would still result in an X server (Xwayland) running though.
I game in desktop mode so I use X11, sometimes with Gamescope in nested for those pretty mangoapp perf stats when testing configs. Works great and I see no need or reason to change it.
You mean as in, out of the box? Because you can install either or both on any distro. I don’t even have an X server nevermind a Wayland thing on most of my installs of Linux.
For gaming you kinda need Xorg to use Gamescope which adds a lot of useful stuff to gaming on Linux that even Windows doesn’t really have on that same level.
If I needed a graphical desktop for productivity I’d rather install Xorg because it has a lot more software support and options (I mean i3) and no actual flaws or downsides I can think of as an end-user and tinkerer.
I fundamentally don’t know what problem Wayland really solves, like PulseAudio is dogshit so something like PipeWire makes sense.
The cybersecurity arguments against X and window isolation in my professional opinion are utterly absurd, anything with that level of access will have access to all that shit in virtually every other way.
I didn’t say most. I said many. As for why and whether it’s a good thing, that really isn’t up to anyone but the people working on said distros. I’m not gonna argue with you over it, because I don’t really care either way. But it looks like things are moving in that direction, and I wouldn’t be surprised if SteamOS defaults to running things under Wayland in the future.
It’s not like it’s particularly hard to tell KDE not to log in to a Wayland session, so I don’t see the harm in it if they do.
Wayland support.
People should remember not all Desktops have stable wayland support or rarely no wayland at all.
The DEs practically everyone is using - minus Cinnamon, for now - have great Wayland support and have Wayland as the default session. Other smaller DEs and WMs have it on their roadmap.
Yep exactly
Yikes! Thanks but still sticking with Xorg. Even the steamdeck is on Xorg.
Steam Deck uses gamescope, Valve’s own Wayland compositor in game mode.
It uses X11 in desktop mode, but I am sure they will change to Wayland there as well, since plasma 6 uses Wayland by default.
Yes I am aware of what gamescope is.
But you actually aren’t.
https://github.com/ValveSoftware/gamescope
Gamescope is a traditional normal compositor like Compiz or Picom, it is a “micro-compositor” in the sense that it is specifically targeted at gaming and full-screen applications to run in an isolated sandbox desktop session with a more suitable implementation of V-sync and native FSR and doesn’t necessarily implement things expected of a standard compositor like Compiz or Compton, which really are tailored more towards supporting interactions between various elements inside a WM, e.g. like transparency.
Normally the chain goes like this: Xorg (a display server) -> DisplayManager (more accurately described as a login manager like SDDM) -> Compositor <-> WindowManager.
A “Wayland compositor” is a semi-related partially overlapping concept with “Compositor”.
Because Wayland is an entirely different protocol that wasn’t made over 20 years ago, the separation between Window managers, display servers and compositors doesn’t apply in the same way, a “Wayland Compositor” incorporates some features of both a traditional WM and a traditional compositor, like if i3 had its own Compiz. Additionally these will also incorporate some features that were previously handled by Xorg or a display server.
You can probably guess at why this is if you recall one of the biggest earlier limitations of Wayland that have severely hampered it’s adoption and compatibility with various software, like Guake, for instance, and led to development of alternatives in lieu of ports :)
Kwin (as in the WM bundled with Plasma/KDE) under Wayland acts as a “Wayland Compositor” for instance, but under Xorg it’s just both a Compositor and a Window Manager.
As such, Gamescope isn’t a “Wayland compositor” at all, in fact running it in both gaming mode and nested mode runs an X server (Xwayland).
It’s also worth noting that Gamescope doesn’t even support Wayland hosts by default since it relies on Xorg stuff to do some of the magic, if you play with the resolution and display stuff in the launch parameters from terminal in nested mode (such as on the deck in desktop mode) and look at the log/debug/error output it should become fairly obvious why this is the case as well.
https://wiki.archlinux.org/title/Gamescope
WRT the Steam Deck, in gaming mode it actually runs an X server (Xwayland, a wayland -> X compatibility layer for compositors), then Gamescope within with MangoApp for the performance stats.
SSH while it’s in game mode and see for yourself.
TL;DR: Gamescope uses Xwayland (an X server), but it’s not a “Wayland Compositor”, it’s just a compositor.
But you can also run Gamescope steam big picture in a Wayland session if you wish from your DM of choice if the arch wiki is to be believed. I’m not sure if this would still result in an X server (Xwayland) running though.
I game in desktop mode so I use X11, sometimes with Gamescope in nested for those pretty mangoapp perf stats when testing configs. Works great and I see no need or reason to change it.
Thanks for the writeup! I am happy to have been corrected and will go do some further reading.
But for how long? Many distros are switching to Wayland, and there’s no reason to assume SteamOS won’t follow suit in the future.
“most distros are switching to Wayland”
You mean as in, out of the box? Because you can install either or both on any distro. I don’t even have an X server nevermind a Wayland thing on most of my installs of Linux.
For gaming you kinda need Xorg to use Gamescope which adds a lot of useful stuff to gaming on Linux that even Windows doesn’t really have on that same level.
If I needed a graphical desktop for productivity I’d rather install Xorg because it has a lot more software support and options (I mean i3) and no actual flaws or downsides I can think of as an end-user and tinkerer.
I fundamentally don’t know what problem Wayland really solves, like PulseAudio is dogshit so something like PipeWire makes sense.
The cybersecurity arguments against X and window isolation in my professional opinion are utterly absurd, anything with that level of access will have access to all that shit in virtually every other way.
I didn’t say most. I said many. As for why and whether it’s a good thing, that really isn’t up to anyone but the people working on said distros. I’m not gonna argue with you over it, because I don’t really care either way. But it looks like things are moving in that direction, and I wouldn’t be surprised if SteamOS defaults to running things under Wayland in the future.
It’s not like it’s particularly hard to tell KDE not to log in to a Wayland session, so I don’t see the harm in it if they do.