Is anyone using DirectFB?

Just wondering if anyone is using SDL’s DirectFB support at this point. I’m not even sure if it compiles. If it’s totally abandoned, I’d like to consider removing it. Please let me know if this is still useful code to have in SDL2!


I’m currently using it on Retropie, and as a result I may consider using it again under Linux as well.

1 Like

DirectFB, or framebuffer(unaccelerated) are very useful for many non-GPU embedded device, please not long keep DirectFB, also reactivate framebuffer support on SDL2. I use SDL1 on two products, and there are people on the old mailing list begging for framebuffer support with SDL2.x. There are way more chips that can benefit from SDL that has no GPUs in the field.

1 Like

I built it a while ago as a bit of a daft experiment for a set top box platform. It mostly seemed to work though I think I had to patch one bit to stop it from crashing but that might just be due to the (fairly ugly!) DirectFB backend the platform in question has.

1 Like

Okay, sounds like DirectFB is still in use.

How hard is it to add back framebuffer support to SDL2? DirectFB is not very active these days anyways, but framebuffer will live forever, even wayland will have framebuffer compatible mode, again, plain framebuffer is the only thing many many embedded devices can use for its GUI in the field, please consider getting framebuffer supported in SDL2.

Adding /dev/fb support back would be cool; I’ll see what it would take to do so.

Yes - DirectFB is used by embedded linux developers who want to use SDL2 on small boards - eg automotive, aeronautics, manufacturing etc etc . Below is the source code snippet from Buildroot - a widely used tool by embedded linux developers - for DirectFB in SDL2. If DirectFB is removed from SDL2, this code will have to change and it would impact use of SDL2 in the embedded linux community.

I personally depend on the SDL2 DirectFB video interface for my project. I have helped in migrating the SDL2 suite to Buildroot for embedded linux developers. I would prefer if DirectFB for SDL2 was not removed.

Peter Thompson

SDL2_CONF_OPTS += --enable-video-directfb
SDL2_CONF_ENV = ac_cv_path_DIRECTFBCONFIG=$(STAGING_DIR)/usr/bin/directfb-config
SDL2_CONF_OPTS += --disable-video-directfb


I am using directfb support in SDL2 to create an on-screen touch keyboard for mobile phones for decrypting the rootfs on boot. Many of these devices we support do not have DRM support in the kernel, so using a framebuffer device (through directfb) is the only way to get video on them.

One followup here, just so I’m clear: people using DirectFB: are you using it because it’s the only path for SDL2 to talk to /dev/fb? And if so, would you rather we just add a /dev/fb target back in (like SDL 1.2 had)?

(or is it something about DirectFB itself you really like?)


/dev/fb would be enough for me.
I only use DirectFB because OpenGL/ES isn’t always available on embedded plateforms, and often, it is buggy.

1 Like

Hi, I’ve used sdl1.2 for quite a few packages in the widely used (maybe 6 people) openwrt-zipit linux distribution because of the /dev/fb support. If a /dev/fb backend was available for sdl2 I’d be able to move forward and use that. Going through DirectFB adds one layer too many for a small device with just a framebuffer and limited RAM.

You can get some idea what I mean by “small device” here.


I am using the framebuffer support of SDL 1.2 for my little GUI-system Geeonx ( I think SDL 1.2 is using DirectFB.

I like it, because I can run Geeonx as GUI and window system + SDL 1.2 without X Windows.

I would be happy if SDL 2 will also provide framebuffer support.

  • Nik -

I came here to say idd in a lot of embedded systems directfb is the only way to go. Native framebuffer support in SDL2 would def. do the trick too.

Also: keep up the awesome work: greatly appreciated!

Interesting to see continued activity in this thread!

It’s worth noting that DirectFB is now very firmly in the “dead projects” category after a few false deaths! The main author, Denis Kropp has now moved onto other projects.

It’s probably still worth keeping around for existing codebases, but I don’t think there will be any new developments in this space.

One of the main backers, Broadcom, are no longer supporting it much.

As to whether /dev/fb support would help, the answer is maybe - if what you’re doing is single window stuff, perhaps it could. DirectFB has a multiapp mode though which wouldn’t be helped by this.

SDL2 is actually potentially useful for migration since it support both DirectFB and GL platforms.

is it the change to CMAKE file ??

why is this error is coming ??

Did this ever come to fruition? I’m looking at a few goofy little linux gameboys, but they’re all super low memory and super old kernel.

No one ever got around to this, sorry. I’ll accept a patch if someone else tackles it, though!