SDL2 with DirectFB backend segmentation fault

Disclaimer: I know the DirectFB backend is not well-supported, and I would be unsurprised if it is soon removed entirely since the disappearance of DirectFB.org, the fbcon backend isn’t available at all in SDL2, and even the Linux framebuffer in the kernel is becoming deprecated in favor of DRM. So I guess I’m asking for trouble, but even if it’s not a long-term solution, I’d like to be able to at least declare victory before I have to install a complete graphics stack.

I’m trying to use SDL+DirectFB to interact with a Qemu virtual machine (no need for multiple windows really), and seeing that Qemu supports SDL, and SDL supports DirectFB, I thought I could keep the host system minimal by avoiding a complete graphics stack with X/Wayland, Mesa, cairo, and dozens of X dependencies.

At first, I noticed that SDL was setting the DirectFB option

Code:

disable-module=linux_input

which happens to be a module I need since I couldn’t get the ‘keyboard’ module working, and linux_input is preferred (according to the DirectFB project) anyway. So I took a look at the code and I found

Code:

/* FIXME: Reenable as default once multi kbd/mouse interface is sorted out /
devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0); /
default: on */

if (!devdata->use_linux_input)
{
    SDL_DFB_LOG("Disabling linux input\n");
    DirectFBSetOption("disable-module", "linux_input");
}

and in the header

Code:

#define DFBENV_USE_LINUX_INPUT “SDL_DIRECTFB_LINUX_INPUT” /* Default: on */

I found the name of the environment variable that overrides this effect. (By the way, notice how the “Default: on” comment is contrary to the actual code?)

So I launch the application with the environment

Code:

SDL_VIDEODRIVER=directfb
SDL_FBACCEL=0
SDL_DIRECTFB_LINUX_INPUT=1

and suddenly the keyboard works. I can see the system booting (the guest’s fbcon – this system has no working GUI at the moment). I can type into login(1) and I get a shell. The mouse works too, for just a few seconds, and then it segfaults. The Control+Alt+F1…6 keys are unresponsive, sometimes I can recover the system using SysRq keys, but ultimately I usually end up rebooting anyway.

Just to be clear, the VM boots up fine, the keyboard works, I can login and interact with the shell, but when I move the mouse for the first time, the cursor moves a few centimeters, but the qemu/SDL/directfb process segfaults within a second or two.

I tried disabling all the mouse modules and using linux-input-devices in ~/.directfbrc so that only the keyboard appears under dfbinfo(1). In this case, the mouse does not work, but when I switch back to the VT where DirectFB is running, a similar segfault occurs.

When I pull up the logs, I see

Code:

Linux Input[647]: segfault at 2c ip <8 hex bytes> sp <8 hex bytes> error 4 in libdirectfb_linux_input.so[<8 hex bytes>+6000]

This looks like a DirectFB bug, but I’ve been unable to reproduce it under other DirectFB applications. The “FIXME” comment also makes SDL my first suspect.

Is this a known bug? Is there a workaround?

The latter part of the segfault log message looks like the function that caused the segfault is in libdirectfb_linux_input.so. I’m assuming that the 8 hex bytes are the address at which the shared object is loaded, and “+6000” is the offset to the particular function. Is there a quick and dirty way to translate that into a function name, using readelf or something, without using GDB?

SDL 2.0.4
DirectFB 1.7.6
QEMU 2.2.1