Display not working on Ubuntu Touch

[Semphriss]

On Ubuntu Touch, windows are not displaying properly. They are stuck in a loading loop.

I've bisected the breaking commit to be ca2c9f6, however I'm not entirely sure how to fix the issue. I'll investigate and provide more information, but I'd need help from experienced SDL developers to make sure the fix I come up with doesn't break anything else.

[slouken]

What is the callstack of the loop?

[Semphriss]

Sorry, I meant to say that the screen is constantly loading. Not sure why I used the word "loop" there.

The underlying code (a very basic SDL app that works fine on Ubuntu desktop) runs normally, and enters the app's main loop without any issue. It renders the window to be a uniform color, which works on desktop, but on Ubuntu Touch, it displays the loading spinner infinitely starting from ca2c9f6. The parent commit works as expected.

I've tried to undo just this change and this change, but the issue persists, so it probably has something to do with the deduplication algorithm.

[slouken]

Yes, what's the callstack while it's stuck loading?

[Semphriss]

I'm not sure I understand, but the code itself never gets stuck; SDL does not report any error and the app continues normally, as if no error happened. The system side of the window displays a loading spinner indefinitely, but it does not hang the app itself; the code keeps running as expected.

I tried to debug on my device, to see if there's any other thread that's stuck, but I struggle to get GDB working. Is there an SDL thread in particular you would like me to check, and/or is there some way to debug windows from the system side?

[slouken]

Ah, I was under the impression that it was looping indefinitely trying to get the correct video driver.

What video driver do you end up with?

[Semphriss]

Wayland; X11 is also supported, but it has to launch a compatibility program (not XWayland, really a separate program) which spawns a new window, and generally does not work well within the OS.

It does work when I force the driver to be X11, but I would prefer to make it work with Wayland if at all possible, and looking at the commit in question and given that it runs well with Wayland prior to that commit, it seems that it's not a problem with Ubuntu Touch's support of Wayland.

[slouken]

Are you sure it's getting wayland? My understanding is that commit only enables Wayland if certain compositor extensions are supported.

Only two outcomes are possible, you either get x11 or wayland. If you set SDL_VIDEO_DRIVER to either one of those, that should bypass the autodetection logic. Does explicitly setting the video driver to both of those values work correctly?

[Semphriss]

I've forced the driver with SDL_SetHint(SDL_HINT_VIDEO_DRIVER, "wayland"); within the app, just before calling SDL_Init. I also print the driver with SDL_Log("Video driver: %s\n", SDL_GetCurrentVideoDriver()); after init to make sure SDL selected the correct driver. I've tried again just to be sure, and it does print "INFO: Video driver: wayland" as expected. I've tried before and after the commit, and it works before and not after.

[slouken]

That's wild. There's literally no change in driver functionality before ca2c9f6 and afterwards. I don't know why it would fail to initialize afterwards.

[Semphriss]

In a few hours, I'll take some time to revert the commit line by line and see which exact part causes the issue.

[Semphriss]

I've narrowed it down: the problem ceases to happen when I give distinct identifiers to the preferred and fallback wayland drivers. By appending _preferred to the preferred driver name, the code that manually sets the driver to wayland will make it use the fallback driver, which works.

I deduce that the preferred driver has some issue that affects Ubuntu Touch, and that the fallback driver doesn't have that issue. I'll try to find out what it is, but analysing the drivers might turn out to be quite a large task. If someone has deeper knowledge about the differences between the preferred and the fallback driver, it would help me a lot.

[Semphriss]

I've narrowed it down even further: the offending line is the call to WAYLAND_wl_display_roundtrip in Wayland_IsPreferred. If I comment just that line, and nothing else, then the window works properly.

In all situations on Ubuntu Touch, SDL attempts to create the preferred driver, fails for some reason, and then attempts to create the fallback driver, successfully. The fallback driver won't display anything unless I comment some code that is specific to the preferred driver; I suspect that a failing preferred driver leaves the environment in an unclean state, which affects the fallback driver.

Has there been testing to ensure that the fallback mechanism works properly? I suppose that a device that supports Wayland but doesn't work with the preferred driver (only the fallback) is quite rare. I'll try to find exactly where it fails on Ubuntu Touch, and then manually make it fail at the same place on desktop; that way, I can see if the problem lies in SDL or Ubuntu Touch.

[slouken]

@Kontrabant, are we missing important information in that first roundtrip during extension detection?

[Kontrabant]

Hmm, maybe we need a round trip after destroying the registry in Wayland_IsPreferred() to ensure that everything is cleaned up before possibly unloading the symbols and libraries and trying again?

@Semphriss, can you try adding WAYLAND_wl_display_roundtrip(display); on line 489 in SDL_waylandvideo.c, after wl_registry_destroy(registry);?

[Semphriss]

@Semphriss, can you try adding WAYLAND_wl_display_roundtrip(display); on line 489 in SDL_waylandvideo.c, after wl_registry_destroy(registry);?

I'm on commit ca2c9f6, I presumed the corresponding line was 418 (between wl_registry_destroy(registry); and the return statement); unfortunately it still fails to display.

[Kontrabant]

The only thing I can think of is that the quick load libraries->initialize to check extensions->unload libraries->load libraries->initialize is causing a problem since it tries the preferred driver, which fails, followed immediately by the regular driver.

Can you try this branch and see if it works? https://github.com/Kontrabant/SDL/tree/video_skip_preferred

This will skip the preferred driver entry if a driver was explicitly requested, as the checks the preferred driver do are irrelevant in this case.

[Semphriss]

It works with the code in the branch 👍 I've retained the code that manually sets the driver; is it good practice to keep it in production on Ubuntu Touch?

[Kontrabant]

I would say yes, at least until we know why it's misbehaving. I'll push the necessary upstream changes.

Out of curiosity, does running it with WAYLAND_DEBUG=1 give any hints as to why it is hanging? If SDL is doing something wrong here, we should fix it.

[Semphriss]

I've run the app with that environment variable set, with both the working commit and latest main 715c187. I've opened and immediately closed the app to avoid filling the log files with repetitive info, but I've left it enough time to display the window (or fail thereof). I haven't seen anything remarkable in the logs, but I'm not familiar enough with Wayland to know what's normal and what isn't.

Here's the logs for the working commit and latest main. There's a random "Video driver: wayland" that's just an SDL_Log located between the call to SDL_Init and the creation of the window.

working.log
not_working.log

[Kontrabant]

Yes, it doesn't look like anything is going wrong in the logs, so this might be some kind of race condition that is out of our control.

I'm pushing the fix to skip trying preferred drivers when a specific driver was requested, so at least your workaround will work.