-
Notifications
You must be signed in to change notification settings - Fork 178
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
SDL apps not working when using SDL_VIDEODRIVER=wayland #1870
Comments
I can reproduce this with testgl2 and testgles2 from the SDL repository at least, works fine in sway. The curious thing I notice is from wayfire log, it says
and no window appears. A hunch is that SDL might be waiting for some protocol call that wayfire isn't making related to these messages. A quick look shows that wayfire callback for |
The two SDL demo clients you linked work on my laptop, I wonder what is different in our setups (and I have verified they are running native wayland). As a first step, it would be interesting to see the output of the SDL app with Also, try disabling as many Wayfire plugins as possible to make sure this is not caused by a specific plugin. |
@soreau Provided additional logs on IRC, so this issue has now been narrowed down to decorations. The bug reproduces only with the following conditions:
It seems that first SDL tries to create a window for SSD. When Wayfire communicates that it prefers CSD, SDL destroys its toplevel and attempts to use Libdecor .. which hangs. I'm still trying to figure out why. |
I figured it out, the bug is indeed in Wayfire. The following patch is enough to fix it: http://ix.io/4EKv I'll merge it in master shortly. The problem was that SDL says a hard 'I need SSD' but Wayfire does not take that into account and forces CSD. |
With the fix, SDL apps will work correctly, however, it may be worth reporting this to the SDL devs as well. SDL appears to have a code path for this which seemingly does not work .. Of course, I'm not sure how to trigger that path without having a bug in the compositor. |
Also, @wb9688 pointed out that another workaround is setting |
Hey people! Thanks a lot!! it was a really quick fix. I was able to confirm both the Wayfire fix (#1871) and the workaround. FWIW, the possibility of having a workaround is really important, so again, thanks a lot.
Ok, will try to create an issue about that on SDL.
FWIW, sorry for not interacting more on IRC. Hard to do that with the summer holidays and three kids at home. |
Done: |
Describe the bug
With all the applications we tried, SDL applications are not working when using SDL_VIDEODRIVER=wayland.
This is desiderable as in some cases it works better when the application tries to set a fullscreen resolution different to the desktop resolution. We also understand that it should be the preferred option, as wayfire is a Wayland compositor.
We initially suspected of a problem with the SDL wayland backend, but then we tested other wayland compositors (weston, sway on rpi4, gnome-shell on a laptop) and it was working fine there.
To Reproduce
This was initially detected with openarena, as part of a work to test different opengl/vulkan applications performance on different scenarios (I'm one of the developers of the rpi4 v3d/v3dv driver). openarena is a well known ioquake3-based project, and usually part of the official repositories of most distributions. So in order to test it:
Then I started to search for smaller SDL applications. So for example:
Expected behavior
Screenshots or stacktrace
As mentioned, on the case of openarena it seems to get blocked, because it doesn't show anything, and using gdb -p, it is always at the same place. The backtrace at that moment:
Wayfire version
All this was detected using system Wayfire (0.7.5-1), but hoping that this issue were fixed upstream, I also tested it from the git repository (so version 0.8.0, HEAD at becc957)
Just in case it was an SDL issue, I tested with SDL from system (2.26.5), and from the git repository (SDL2 branch, HEAD at f032e8c19165aeee6f9b47e82fb56809d4aeae1e)
Something else?
We are willing to debug, and even try to modify/fix the code ourselves, but we would really appreciate some guidance.
The text was updated successfully, but these errors were encountered: