Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
SDLBugzilla opened this issue Feb 11, 2021 · 5 comments · May be fixed by #4306
Open

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

SDLBugzilla opened this issue Feb 11, 2021 · 5 comments · May be fixed by #4306
Assignees
Labels

Comments

@SDLBugzilla
Copy link
Collaborator

@SDLBugzilla SDLBugzilla commented Feb 11, 2021

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

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
Copy link
Collaborator

@flibitijibibo flibitijibibo commented Apr 8, 2021

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:

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

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

Loading

@flibitijibibo
Copy link
Collaborator

@flibitijibibo flibitijibibo commented Apr 14, 2021

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

Loading

@flibitijibibo flibitijibibo linked a pull request that will close this issue Apr 17, 2021
@StarStarJ
Copy link

@StarStarJ StarStarJ commented May 5, 2021

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?

Loading

@flibitijibibo
Copy link
Collaborator

@flibitijibibo flibitijibibo commented May 5, 2021

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

Loading

@StarStarJ
Copy link

@StarStarJ StarStarJ commented May 5, 2021

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

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

3 participants