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

Black screen on SDL2-enabled OpenTTD, Sway and SDL_VIDEODRIVER=wayland #8029

Closed
ya-isakov opened this issue Mar 1, 2020 · 11 comments
Closed
Labels
bug Something isn't working OS: Linux Issues specific to Linux builds

Comments

@ya-isakov
Copy link

ya-isakov commented Mar 1, 2020

Version of OpenTTD

1.10.0-RC1

Expected result

Title screen is shown

Actual result

Black screen, but sound of train could be heard

Steps to reproduce

Compile OpenTTD with SDL2, run it with SDL_VIDEODRIVER=wayland ./openttd under Sway-1.4.0

P.S. Same problem on Weston-8.0.0

@LordAro
Copy link
Member

LordAro commented Mar 2, 2020

First off, we'll probably want to check this isn't some system/SDL issue we can't solve - can you run any SDL2 application?

@ya-isakov
Copy link
Author

ya-isakov commented Mar 3, 2020

I've checked another SDL2-application, JA2-Stracciatella, and there is no black screen or other problems. No issues with Aquaria-OSE as well.

P.S. Every time I've checked that they run in Wayland mode

@glx22
Copy link
Contributor

glx22 commented Mar 3, 2020

Maybe using -ddriver2 flag can give some info

@ya-isakov
Copy link
Author

ya-isakov commented Mar 4, 2020

Here is output with wayland driver

dbg: [driver] Successfully loaded blitter '32bpp-anim'
dbg: [driver] SDL2: using mode 1920x1029x32
dbg: [driver] SDL2: using driver 'wayland'
dbg: [driver] Successfully loaded video driver 'sdl'
dbg: [driver] Successfully probed sound driver 'sdl'
dbg: [driver] Successfully probed music driver 'extmidi'
dbg: [driver] Successfully loaded blitter '32bpp-sse2-anim'
dbg: [driver] SDL2: using mode 1920x1029x32
dbg: [driver] SDL2: using threads
dbg: [driver] SDL2: using mode 1920x1029x32
dbg: [driver] extmidi: set volume not implemented

Pretty similar to x11 driver:

dbg: [driver] Successfully loaded blitter '32bpp-anim'
dbg: [driver] SDL2: using mode 1920x1029x32
dbg: [driver] SDL2: using driver 'x11'
dbg: [driver] Successfully loaded video driver 'sdl'
dbg: [driver] Successfully probed sound driver 'sdl'
dbg: [driver] Successfully probed music driver 'extmidi'
dbg: [driver] Successfully loaded blitter '32bpp-sse2-anim'
dbg: [driver] SDL2: using mode 1920x1029x32
dbg: [driver] SDL2: using threads
dbg: [driver] extmidi: set volume not implemented

@LordAro LordAro added the bug Something isn't working label Apr 4, 2020
@LordAro
Copy link
Member

LordAro commented Apr 4, 2020

Without any developers having a wayland setup to test with, I'm afraid you're going to have to debug this yourself for now, or find someone else who can help

@ya-isakov
Copy link
Author

ya-isakov commented Apr 6, 2020

I've found that use of sdl driver's parameter no_thread fixes this issue. The only change in output with -d driver=2 is using no threads instead of using threads

@zimbatm
Copy link

zimbatm commented Aug 15, 2020

I can reporduce the issue on Sway. After recompiling --without-threads it started working fine.

@TrueBrain TrueBrain added the OS: Linux Issues specific to Linux builds label Jan 2, 2021
@TrueBrain
Copy link
Member

TrueBrain commented Feb 6, 2021

I looked into this a bit. A few things worth mentioning:

SDL uses X11 over wayland, as they themselves do not consider wayland backend driver stable enough to be used by default. See https://bugzilla.libsdl.org/show_bug.cgi?id=3948 . Luckily, the X11 backend works just fine on Wayland.

Mainly as reason they give a patch like https://bugzilla.libsdl.org/show_bug.cgi?id=5194 has not landed yet. There is a lot of activity going on there, so who knows, sometime soon.

Till that time, you will notice that the SDL window has no decoration (you cannot resize, no title, no minimize/maximize button, etc). This makes it impracticable to use for a game like OpenTTD. These are problems SDL appear to be fixing, so it is better for us to hold on this.

The next problem we currently have with Wayland, is that rendering fails. This is because for Wayland, SDL uses EGL. And it appears that the context is created in the main thread, while we render in the draw thread. This is why -vsdl:no_threads fixes that problem. This is most likely also the correct fix for OpenTTD: if wayland backend is detected, disable threading.

TrueBrain added a commit to TrueBrain/OpenTTD that referenced this issue Feb 6, 2021
…eo driver

When the wayland SDL video driver is used, an EGL context is
created in the main thread. It is not allowed to update this
context from another thread, which is exactly what our draw-thread
is trying.

The other solution would be to move all of SDL into the
draw-thread, but that would introduce a whole scala of different
problems.

The wayland SDL backend is significantly faster than the
X11 SDL backend, but there is a performance hit nevertheless.
TrueBrain added a commit to TrueBrain/OpenTTD that referenced this issue Feb 6, 2021
…eo driver

When the wayland SDL video driver is used, an EGL context is
created in the main thread. It is not allowed to update this
context from another thread, which is exactly what our draw-thread
is trying.

The other solution would be to move all of SDL into the
draw-thread, but that would introduce a whole scala of different
problems.

The wayland SDL backend is significantly faster than the
X11 SDL backend, but there is a performance hit nevertheless.
TrueBrain added a commit to TrueBrain/OpenTTD that referenced this issue Feb 6, 2021
When the wayland SDL video driver is used, an EGL context is
created in the main thread. It is not allowed to update this
context from another thread, which is exactly what our draw-thread
is trying.

The other solution would be to move all of SDL into the
draw-thread, but that would introduce a whole scala of different
problems.

The wayland SDL backend is significantly faster than the
X11 SDL backend, but there is a performance hit nevertheless.
@physkets
Copy link

Is the performance hit big enough, that you could maybe add a recommendation to not use the Wayland back-end?

Is the actual solution, figuring out how to draw on a separate thread, when using EGL contexts?

@TrueBrain
Copy link
Member

Is the performance hit big enough, that you could maybe add a recommendation to not use the Wayland back-end?

There are two things here.

  • As mentioned, the recommendation is NOT to use the Wayland video driver, as indicated by SDL. It has known issues SDL is addressing. This is why it is not default yet. This has nothing to do with us, but that does mean the recommendation is not to use it.
  • The performance hit is not big enough, otherwise we would not have solved it this way. It for sure is measurable, and that is the reason I mentioned it, but it is nothing that will break anyone's gaming experience.

Is the actual solution, figuring out how to draw on a separate thread, when using EGL contexts?

No. That would be a huge change in all our video drivers (and all the problems that comes with such endeavor), one not worth taking at this point in time for a single SDL video driver that should not be the default on any system :)

@ya-isakov
Copy link
Author

ya-isakov commented Jan 4, 2023

@TrueBrain BTW, statement about not recommendation of Wayland from SDL2 is not valid anymore, according to https://www.phoronix.com/news/SDL2-Prefers-Wayland and libsdl-org/SDL#4306

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working OS: Linux Issues specific to Linux builds
Projects
None yet
Development

No branches or pull requests

6 participants