How do I tell which display server my session is using, and when is it worth switching?

Checking takes one command:

echo $XDG_SESSION_TYPE

It prints x11 or wayland. If it prints nothing useful, loginctl show-session $(loginctl | grep $USER | awk '{print $1}') -p Type gets there the long way.

Switching is usually a choice on the login screen: click your username, and there is a settings control — often a small gear — offering the session types your desktop has installed. It is a per-login choice, so you can go back immediately if something breaks.

And your two symptoms are exactly the classic ones, which is a good sign your suspicion is right.

What actually differs, and why your two problems happen:

Screen capture. Under the older server, any application could read the whole screen, including other windows and your keystrokes. That is convenient and it is also a serious weakness. The newer server forbids it, and capture goes through a permission-mediated portal instead. Applications that have not been updated to use the portal capture a black rectangle or nothing — which is your screen sharing tool.

Global shortcuts and input injection. Same root cause. Grabbing keys globally or injecting input into another application is restricted, so automation tools and some shortcut managers do not work as they did.

So these are not bugs, they are the security model. The fix is a version of the application that supports the portal, and for most popular tools that now exists.

Other real differences: per-monitor scaling and mixed refresh rates work considerably better on the newer one, and older or proprietary graphics drivers occasionally work better on the older one.

On whether to switch: the honest answer is that for most people on current hardware the newer server is now the better default, and the exceptions are specific rather than general.

Reasons to stay on the older one, all legitimate:

• An application you depend on that has no portal support and no replacement.
• Remote desktop or accessibility software that only works there.
• An older or unusual graphics setup where the newer stack is unstable.
• Screen recording or streaming workflows built on unrestricted capture.

Because it is a per-login choice, the sensible approach is to try it for a week, keep a list of what breaks, and go back if the list is unacceptable. There is no migration and nothing to undo, which makes this a much lower-stakes decision than it reads.

One practical note if you do switch and something misbehaves: check whether the application is running through a compatibility layer.

Many applications still run as older-protocol clients inside the newer session via a translation layer, and a fair number of the odd behaviours come from that rather than from either server. Some applications have a flag or a setting to run natively, and turning it on fixes scaling blur and input quirks in one step.

Worth checking per application before concluding the session type is the problem.