Using SDL2 in Yocto Build

I’m a bit of a newbie with regard to my target’s desktop environment. Even if I was using Torizon, I’m not fully understanding a few things here…

First, a couple questions related to using a Yocto based build/image on a Verdin w/ iMX8M Mini…
I am using the standard Yocto build and produced the SDK. I want to build/use an SDL2 based application. In the Yocto build, I need to ensure SDL2 is being built according to the desktop environment described below in the multimedia demo image.

The standard multimedia image that supports Qt includes SDL2 as part of the build, but the libraries to link an SDL2 application are not included in the SDK. The shared libraries are present in the sysroot though. Can I add to a recipe variable to include those libraries in the SDK build? I copied the archive files to my SDK install so I could link, but this was a manual step. All the SDL2 headers are present for building, but a CMake-based build can’t find the .a files unless I copy them from my build setup and place them manually. The .so files are also present on the target device.

Perhaps more important is that an SDL2 application doesn’t run properly on the desktop provided by the standard multimedia image. I believe it’s running Wayland, but the whole X11, Wayland, XWayland thing is mind numbing. I can build and run a Qt application no problem now. SDL2 applications show a blank screen and do nothing.
So…what changes to this desktop environment (and my build) do I need to utilize SDL2 properly? Is there a better image option I should build and install to get an SDL2 application running (with Wayland)? I’m clearly “not clear” on this matter and need to be straightened out.

A Qt application built using the cross compiler settings clearly recognizes the desktop environment, but an SDL2 application doesn’t, so how do I differentiate and build accordingly?

Is there a daemon or similar that needs to be running and is not part of the demo image build?

Hi @mswtech

Regarding the SDK, I did a quick build here and I see files such as and SDL_version.h in the extracted contents. I was able to cross-build a basic SDL example using the SDK. What specific build errors are you seeing?

As for running the applications, this link seems to suggest that setting SDL_VIDEODRIVER=wayland might be what you need. I’ve never actually run anything like this so I don’t know if that’s accurate but should be a quick enough test.


Thanks for checking this. So with the SDK, I couldn’t locate the archive file, as my post indicated. I ended up copying it manually. How did you build the application? Cross compile? Which .a file did you link to? Yeah, all the header files are present in the SDK installation, but I could not find the proper archive to link against in order to use the shared library that’s on the distro.

I followed that link. Didn’t help in my case. Since you built the SDK (and image) as well as a test application, can you please run it on the target and see it it runs? I only get a blank window. If yours runs, that would perhaps indicate compiling (or linking) against an incorrect library or similar or just having the wrong build options to run in the Weston/Wayland environment.

In my case, I was able to follow the instructions from here to build a simple window app that worked.

The actual build commands run by the Makefile are:

aarch64-tdx-linux-gcc  -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/work/dmoseley/scratch/tdx/sysroots/aarch64-tdx-linux -D_REENTRANT -I/work/dmoseley/scratch/tdx/sysroots/aarch64-tdx-linux/usr/include/SDL2   -c -o window.o window.c
aarch64-tdx-linux-gcc  -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/work/dmoseley/scratch/tdx/sysroots/aarch64-tdx-linux -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fstack-protector-strong -Wl,-z,relro,-z,now  window.o  -lSDL2 -o window


Thanks I will try doing this using your same settings to see what happens. Did you build and run it to see if the window worked properly?

Yes, I was able to run it on my apalis-imx8 running the 6.2.0 release of the Multimedia image.


Well, I THOUGHT this worked. I used the console window available from the desktop on the iMX8MM after filling the Qt app. If I use
SDL_VIDEODRIVER=wayland ./main (my application name is main), it gives the error:
Window could not be created! SDL_Error: failed to create an EGL window surface

I tried running from a desktop console window as well as via the console connection via serial…

If I run it without the environment variable setting, the window does popup. However, when the mouse enters over the window, it disappears.

Again that is true from either the console window on the desktop or via the console. Via SSH, the behavior is exactly the same.

So, even though the window appears, is it really working correctly? I’m going to try and expand the example you provided the link to see if there’s a necessary even pump or something in SDL2.

OK. That’s good feedback. It could very well be a missing packageconfig or something. Let me know what you find.


Still need your assistance/guidance here. No mouse events when entering the window at all. Passing that environment variable doesn’t help. What is the desktop being run in the standard multimedia image? Qt apps clearly work as I was able to build a test. I see the wayland-app-launch.service and weston.service running. Can you please enhance your test app to see if you can get mouse events, etc.? There’s something fundamental that’s being missed here in the application or environment in general where window creation seems to partly work but events aren’t being passed through or something…

I’m honestly not sure there is a desktop environment in the reference image. It’s not really intended as anything more than a demo platform for showing off some basic multimedia stuff. I know we are based on the “wayland-egl” QT_QPA_PLATFORM but I don’t know if that’s the answer you are looking for.