[patch] Wayland: SDL applications start in XWayland by default

[SDLBugzilla]

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• prefer-wayland-over-x11.patch (prefer-wayland-over-x11.patch, text/plain, 2019-10-23 14:14:00 +0000, 814 bytes)

Reported in version: 2.0.10
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2017-11-07 21:42:34 +0000, Andrey Alexeyev wrote:

This is because SDL prefers the X11 driver. If XWayland is running on the default display, SDL will happily settle for it, even if the Wayland driver could be used instead.

This is far from ideal. I've experienced subpar performance and visual artifacts, both specific to XWayland, in my OpenGL game.

Applications can work around this by attempting to initialize video with the Wayland driver explicitly first.

This issue probably applies to every other video system where an X11 compatibility layer could be present, e.g. Mir, though I haven't tested that.

Simply moving X11 lower on the priority list should fix this.

On 2019-10-23 14:07:49 +0000, David Heidelberg (okias) wrote:

I believe this patch [1] solves this issue. It's took from new linux Librem 5 phone gitlab [2].

Since two years passed and Wayland became preferred solution in Linux world, would make sense to prefer it over X11 backend?

[1] https://source.puri.sm/Librem5/libsdl2/raw/997f974c1d0a3acb869cee956c06ba33480f5e58/debian/patches/prefer-wayland-over-x11.patch
[2] https://source.puri.sm/Librem5/libsdl2/commit/997f974c1d0a3acb869cee956c06ba33480f5e58

On 2019-10-23 14:14:00 +0000, David Heidelberg (okias) wrote:

Created attachment 4017
prefer-wayland-over-x11.patch

On 2019-10-23 16:49:05 +0000, Ryan C. Gordon wrote:

(In reply to David Heidelberg (okias) from comment # 1)

Since two years passed and Wayland became preferred solution in Linux world,
would make sense to prefer it over X11 backend?

SDL's wayland target needs client-side decorations in some form, at a minimum, before it can be favored over X11.

This is definitely not going to happen for 2.0.12.

--ryan.

[flibitijibibo]

I've been hammering at this for quite a while and I'm now pretty comfortable in saying that this is extremely close to being usable by default. The TODO, as far as I can tell:

• Client-side decorations (Wayland: Windows have no border and title bar #1625, wayland client-side decorations #3739, PR wayland client-side decorations #4068)
• Display mode fixes for high DPI
• Keyboard mapping updates
• Dead key support
• Clipboard fixes

Once that's done, these three blocks have to be switched around:

SDL/src/video/SDL_video.c

Lines 64 to 69 in 27b74d3

	#if SDL_VIDEO_DRIVER_X11
	&X11_bootstrap,
	#endif
	#if SDL_VIDEO_DRIVER_WAYLAND
	&Wayland_bootstrap,
	#endif

SDL/src/video/SDL_video.c

Lines 4042 to 4047 in 27b74d3

	#if SDL_VIDEO_DRIVER_X11
	#include "x11/SDL_x11messagebox.h"
	#endif
	#if SDL_VIDEO_DRIVER_WAYLAND
	#include "wayland/SDL_waylandmessagebox.h"
	#endif

SDL/src/video/SDL_video.c

Lines 4150 to 4163 in 27b74d3

	#if SDL_VIDEO_DRIVER_X11
	if (retval == -1 &&
	SDL_MessageboxValidForDriver(messageboxdata, SDL_SYSWM_X11) &&
	X11_ShowMessageBox(messageboxdata, buttonid) == 0) {
	retval = 0;
	}
	#endif
	#if SDL_VIDEO_DRIVER_WAYLAND
	if (retval == -1 &&
	SDL_MessageboxValidForDriver(messageboxdata, SDL_SYSWM_WAYLAND) &&
	Wayland_ShowMessageBox(messageboxdata, buttonid) == 0) {
	retval = 0;
	}
	#endif

Christian is working on libdecor, I just wrapped up clipboard fixes, the keyboard stuff might be out of my range so both of those are up for grabs.

[flibitijibibo]

The last of the list was just merged into main - now CSD is the only blocker for real this time, I hope. I had this written down internally, but I don't think this is necessary to ship:

xdg-decoration/libdecor stuff:
    - SetWindowIcon
    - GetWindowBordersSize

Maybe in the spec, I think:
    - GetDisplayBounds
    - GetDisplayUsableBounds
    - GetDisplayDPI
    - SetWindowModalFor
    - SetWindowInputFocus
    - HideWindow
    - RaiseWindow
    - XTranslateCoordinates equivalent for IME rectangle

[StarStarJ]

Will this get a fallback to xwayland for non GLES apps/contexts, or will you wait for mesa drivers to catch up with desktop OpenGL drivers without GLX dependency?
Just wondering, if it won't break alot of stuff.
Testing the linked PR with mesa 21.2 on amdgpu wouldn't work yet.

And another question
Will SDL somehow provide a way to check if the default context profile would be ES, e.g. by setting ES context as default value for SDL_GL_CONTEXT_PROFILE_MASK, so that you can programmatically setup GLES stuff for you application?

[flibitijibibo]

To the best of my knowledge Wayland does not default to ES, it just happens to use EGL for WSI - the opengles.c filename is kind of misleading in Wayland's case.

On my AMD test environment it uses desktop GL unless I explicitly set the ES flag. An environment that defaults to ES is going to have problems regardless of display server, forcing desktop GL would probably be a very common workaround for end users on that system.

EDIT: See #4358

[StarStarJ]

Ah thats good to know. I'm not too much into all these driver things, just read on some stackoverflow that the GLX dependecies in the mesa drivers don't allow native wayland to use desktop OpenGL, which appearntly is wrong then.

Thanks for the quick response.

Edit
Just had to build GLEW with EGL support and set the SDL hint SDL_HINT_VIDEO_X11_FORCE_EGL to 1.
Now it works fine also with shipped SDL and GLEW. Thanks again