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.
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.