Hi,

I'm currently packaging liballegro 4.4.2 for the OpenWRT-based firmware of the NanoNote mini-computer, and stumbled into the following framebuffer driver bug:

The symptom is that all allegro programs that do set_gfx_mode twice, once with a gfx_autodetect and then a second time with gfx_save, fail to initialize the graphics device if the first set_gfx_mode() fails. The first one fails pretty often on the NanoNote, since it only supports a single mode: 320x240x32bpp, and so most programs just fail.

The culprit is fb_init(), which closes the frame buffer device ('close(fbfd)') when it fails to setup the requested video mode. The device is then never re-opened, as there is an "optimization" at the start of fb_init() where it first checks that fb_mode_read is false:

So after the first call to fb_init(), the fbfd file-descriptor is invalid and all subsequent attempts to set up a video-mode fail. I patched it for now by adding fb_mode_read=FALSE before exiting.

My patch is here:

http://projects.qi-hardware.com/index.php/p/openwrt-packages/source/tree/trunk/liballegro/patches/020-fix-fbcon-init.patch

Most of it is joust 'noise' adding tracers to see what's going on. Also the patch doesn't catch all the places where fb_init() closes fbfd, only the one occurrence that was a problem for us.

Maybe somebody with more understanding of the driver could have a look at what's a proper fix. Maybe the check for fb_mode_read should be replaced with a check for 'fbfd>=0' because "mode read" and "fb descriptor valid" seem to be two different things altogether.

cheers,

David