Dilan

The general lesson transfers well beyond this ecosystem: whenever the editor and the build disagree, believe the build.

The same split exists in almost every toolchain. The editor's analyser is a convenience layer that approximates the build, and there is a mechanism somewhere to feed it the real thing — a compilation database, a generated configuration file, a project index.

Worth learning what that mechanism is for whatever you work in. It converts a permanent low-grade annoyance into a solved problem, and it also fixes autocomplete and go-to-definition, which are the things you actually lose.

For a handful of important machines, there is a fourth option worth mentioning: give them fixed addresses and stop depending on name resolution for the things that matter.

The hub, the server and the printer having addresses that never change means that when DNS is broken — and at some point it will be — you can still reach the things you need to fix it. That has saved me more than once, and it costs nothing.

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.

One way to find out whether this is actually your problem rather than guessing: leave a continuous ping running to the hub from another machine for a day, and log it.

If you see periodic gaps or spikes into hundreds of milliseconds, you have your answer and it is not the configuration. If the network is flat and things still misbehave, you have saved yourself buying a cable and can look elsewhere with confidence.

Measuring first is cheaper than either the cable or the week of debugging.

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.