Building SDL2 on Vero 4K


I recently upgraded my Raspberry Pi 2 to a Vero 4K and I’m trying to set everything up as I had it.
I’m trying to build scummvm on the Vero 4K, but it has a requirement on SDL2.

On the rpi2 I had problems installing SDL2 from raspbian since it pulled other packages that broke the GL libraries from the raspberry, replacing symlinks to the mesa libraries, so I had to build SDL2 and install it on /opt/sdl.

I’m trying to do the same with the Vero4K (building SDL 2.0.7) and for that, I’m trying with:

$ ../configure --prefix /opt/sdl/

And I get:

Enabled modules : atomic audio video render events joystick haptic power filesystem threads timers file loadso cpuinfo assembly
Assembly Math   :
Audio drivers   : disk dummy oss alsa(dynamic)
Video drivers   : dummy opengl_es2 vulkan
Input drivers   : linuxev linuxkd
Using libsamplerate : YES
Using libudev       : YES
Using dbus          : YES
Using ime           : YES
Using ibus          : NO
Using fcitx         : NO

After building SDL2 and scummvm, when I try to run scummvm it fails with Could not initialize SDL: No available video device! so I tried the testgles2 example on SDL2 and it also says INFO: Couldn't initialize video driver: No available video device.

Looking at the code I’ve noticed that SDL2 has a special video driver for raspberry (obviously not built on the vero since it relies on bcm_host). Would SDL2 need a special video driver for Vero 4K too that uses the Mali driver? Is there any way to get a functional SDL2 library working?



Try installing Vero 3’s userland headers:

sudo apt-get update
sudo apt-get install vero3-userland-dev-osmc

And pass the GLES libraries at build time:

export CFLAGS="-I/opt/vero3/include -L/opt/vero3/lib"

Then re-run ./configure and make

Stop Kodi before trying to run anything:

sudo systemctl stop mediacenter


Thanks @sam_nazarko,

Yes, I already installed that package and used those flags before posting the message above.
To do the tests I quit kodi, press ESC, and log in into a text terminal.

Anyway, I managed to advance a bit. After some searches on the internet I found this: GitHub - mihailescu2m/libsdl2-2.0.2-dfsg1 which implements a mali fbdev driver with libsdl 2.0.2, and with that, I’ve done a quick test and it’s “working” (though not completely)

I’ve taken the latest SDL from github and I’m in the process of updating the changes done by mihailescu2m so they can be submitted upstream to the SDL developers.


Neat. This might be worth a HOW-TO. IIRC, Retrosmc uses SDL for some emulators, so it may be beneficial there.


Hi, I just wanted to say thank you for sharing your WIP. It’s very timely for me. Personally I’m trying to get Mupen64Plus onto the Vero4k. Some successful compilation, not so successful execution and on the last attempt I borked the box, I think because of the SDL2 I tried my luck with… So I’m about to try building SDL2 myself.

I’ve been looking at Odroid-C2 activity because of the supposed similarities and recently came across this retropie post where they recommended the SDL2-mali from here.

Turns out they added mali-fbdev support from the git you posted about 2 years ago. Don’t think it went any further upstream than that so far, so I don’t think you’re duplicating anything.

Keep up the good work and I hope you get playing The Secret of Monkey Island soon!

That takes me back…

1 Like

Thanks for the links! I wasn’t aware of that retropie post nor their SDL fork from 2.0.4 . From a quick look it seems (as you said) that the mali-fbdev code is exactly the same as the github repository I found, but it’s interesting anyway to have all the related information on this thread.

I haven’t had much time lately, but I hope in the next days I’ll make some progress (and I’ll check more carefully if the retropie developers did any other change). I’ll keep you informed.


Was audio the problem by any chance?

I’ve been dipping in and out of this all week and have SDL2, Mupen64plus and all of it’s plugins working. Or so I think. The video and input are definitely live under the emulator and I’ve got it running fullscreen. The performance is far smoother than the RPI3! Will have to write it up when it’s finished.

The only issue I have now is the audio with:

ALSA lib pcm_direct.c:896:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
ALSA lib pcm_dmix.c:1034:(snd_pcm_dmix_open) unable to initialize slave
Audio Error: Couldn't open audio: ALSA: Couldn't open audio device: Invalid argument

The SDL test programs didn’t seem to include anything for audio so I don’t know if this is SDL or the audio plugin. Does audio work under scummvm?

No matter what I always post too soon. Found the SDL audio tests…

testaudioinfo yields:

INFO: Built-in audio drivers:
INFO:   alsa
INFO:   dsp
INFO:   disk
INFO:   dummy
INFO: Using audio driver: alsa
INFO: output devices:
INFO:   System audio output device
INFO: capture devices:
INFO:   No capture devices found.

And loopwave yields:

INFO: Available audio drivers:
INFO: 0: alsa
INFO: 1: dsp
INFO: 2: disk
INFO: 3: dummy
ALSA lib pcm_direct.c:896:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
ALSA lib pcm_dmix.c:1034:(snd_pcm_dmix_open) unable to initialize slave
ERROR: Couldn't open audio: ALSA: Couldn't open audio device: Invalid argument

So I guess the question still stands, is your SDL build working any better than that?

UPDATE - fixed it - hopefully for both of us.

ALSA should have a config file that has not been created by any of the processes up to this point.

It can be:




I did an /etc/asound.conf of:

pcm.mmap0 {
    type mmap_emul;
    slave {
      pcm "hw:0,0";

pcm.!default {
  type plug;
  slave {
    pcm mmap0;

ctl.!default {
  type hw card 0

No errors.
Now what it sounds like is hard to judge from 26 miles away, so I’ll check on that tonight. I’m also worried it’ll have broken something OSMC/kodi related, so that to test also.

The sound genuinely works in emulator with these settings.

However, kodi does not like it, so either:

  1. A more complex setting is required (I’m looking into it).

  2. The configuration file must be deleted/hidden prior to starting kodi, by whatever wrapper script is employed for the emulator (trivial).