0.53.0/sync Daemon broke on XWayland

[necessarily-equal]

since commit 60d055c, daemon broke on XWayland, and thus on Wayland because the X11 backend is still the default. SDL_BACKEND=wayland fixes it.

Warn: Couldn't get window display mode: Couldn't find display mode match
Warn: GLimp: Unknown error for mode 3
Warn: Couldn't load a renderer.

reverting the commit makes it work anew. (to test, checkout 2abcb3fca on Unv, git submodule update --init --recursive, cd daemon, git revert 60d055c19138eff19e16c934107194520017dc89)

I'm not sure why is that. I think this is because unv tries to do forbidden things on xwayland, as the screen flickers a lot when I open or select the unv window on Xorg.

I think this is blocking for the 0.53.0 release

[necessarily-equal]

a "last resort" workaround that we can consider is to force set SDL_VIDEODRIVER=wayland if we detect wayland is used.

It's kinda ugly, but Unvanquished works ok on wayland, modulo the issues tracked in #482. I'm not sure it has been tested enough to be the only and default backend.

[illwieckz]

The issue looks more complex, it may even not be related to Wayland at all.

When trying to render on a window larger than what the GPU hardware supports, the engine would crash with a segmentation fault. Unfortunately it looks like the only error we manage to catch before the engine executes the code that will do a segmentation fault is “Couldn't find display mode match”.

So I thought it was a good idea (but maybe I was wrong) to catch that error to restart the engine with a safe resolution instead.

But in fact, doing that may prevent to do many valid usages.

If I understand correctly, the “Couldn't find display mode match” error happens when we try to open a window that is not the size of a resolution supported by the screen (not the GPU!). So it would not work if we try to open a window that is larger than the screen (as the screen would say this is not a fullscreen native resolution), but it would probably fail as well when trying to open a window that has a custom resolution that is not part of the native screen resolutions, even if smaller than the native screen resolution (like opening a window of size arbitrary 2000×1234 on a 3840×2160 screen). If some windowing system even hide some hardware limit this may even happen as well.

Catching “Couldn't find display mode match” to prevent segfault when the GPU hardware didn't supported the resolution was not that a bad idea because to begin with, the display server would never starts with an unsupported resolution so the GPU hardware limit actually matches the display limit.

But unfortunately the display limit looks to be meaningless in many situations and we better want to ignore it in those situations.