Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
A Framebuffer animation daemon for embedded systems running Linux
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
A framebuffer animation daemon bannerd is a very simple program that reads several bitmap files, forks into background and renders them to framebuffer with the configured interval. Since all the decompression (if any) work is done at the start, there is very little overhead when the animation is rendered. The only thing that the program does is memcpy() at the necessary 32 bit aligned location and then sleep until next frame. It is mainly intended to be used in embedded Linux systems to display e.g. boot animation. For use on desktops many more powerful programs are available, e.g. Plymouth (http://www.freedesktop.org/wiki/Software/Plymouth) and usplash (https://launchpad.net/usplash). Animation that bannerd renders consists of several frames read from BMP files in the order given in commandline. It is displayed with configured interval in milliseconds or with the default 24fps frequency. It can also consist of one frame in which case the program can be made to immediately exit, leaving it on screen. Each frame may have different size but is centered on the screen. The complete form of its usage is: bannerd [options] [interval[fps]] frame.bmp ... -D, --no-daemon Do not fork into the background, log to stdout -v, --verbose Do not suppress debug messages in the log (may also be suppressed by syslog configuration) -c [<num>], --run-count[=<num>] Display the sequence of frames <num> times, then exit. If <num> is omitted, repeat only once. If it is less than 1, ignore the option -p, --preserve-mode Do not restore framebuffer mode on exit which usually means leaving last frame displayed -i <fifo>, --command-pipe=<fifo> Open a named pipe <fifo> and wait for commands. The pipe should exist. If -c is specified, it is ignored. See bannerd(1) man page for command syntax. interval Interval in milliseconds between frames. If 'fps' suffix is present then it is in frames per second. Default: 41 (24fps) frame.bmp ... list of filenames of frames in BMP format REQUIREMENTS The program needs a framebuffer driver compiled into the kernel, and it of course uses device node /dev/fb0. This one may not be available on your board if you are making a root filesystem by yourself or if you use udev/mdev and try to run bannerd before any of them creates this device node (e.g., early at boot time). In this case create the device node if it does not exist by inserting something like [ -c /dev/fb0 ] || mknod /dev/fb0 c 29 0 into your boot scripts. You need to execute the program with sufficient permissions to open and write to framebuffer. If you use OMAP CPU, you may need to hack the source code a bit before compiling. omapfb driver does not display contents of the framebuffer unless you ask it to, so you may need to insert a call to fb_omap_update_screen() into main loop (in main()) just after fb_write_bitmap(). USAGE EXAMPLES To continuously display animation of 8 frames with movie speed (24 frames per second), you could use # bannerd 1.bmp 2.bmp 3.bmp 4.bmp 5.bmp 6.bmp 7.bmp 8.bmp or just # bannerd ?.bmp If you want a slower delay between frames, you can specify in in milliseconds # bannerd 1000 ?.bmp When you no longer need the displayed animation, you can kill the program by # pkill -TERM bannerd If you want the program to run once through the sequence of frames and then exit by itself, you can use # bannerd -c1 ?.bmp A useful way to display a single image and exit, leaving it on screen, is # bannerd -pc image.bmp LIMITATIONS The program supports only BMP format. Support for other fomats would require either implementing parsers from scratch or an external dependency on a library which is not desirable for some embedded systems. Configurable support for PNG and some other formats will be added later, though. BMP formats recognized by the program are: 16bpp (ARGB4444, XRGB4444, RGB565, ARGB1555, XRGB1555), 24bpp (RGB888), 32bpp (ARGB8888, RGBA8888, RGBX8888). Monochrome, 2bpp, 4bpp and 8bpp images are not supported. Bitmaps must be either uncompressed (most common format) or use bitmasks. All the bitmap data is kept in memory in 32bpp mode to simplify rendering and not worsen 32bpp bitmap quality at the same time. This means considerable amount of memory consumed by the process for large animations: for a 800 x 480 32bpp bitmap 1500kB of memory are needed. Thus, long fullscreen animations may require a lot of memory. At the moment, alpha blending of images is not supported. SUPPORTED PLATFORMS The program is supposed to run on any Linux that has a framebuffer. Its functionality, of course, depends on the framebuffer driver (e.g., whether it can display images in ARGB32 mode). The program has been tested on i686 :P and ARM i.MX28 boards. If you have tested it on your board and it does not work as expected, please contact the author(s). It will be very nice to know what is the problem there and to fix it for as many platforms as possible. AUTHOR Questions and suggestions are highly appreciated. If you have something to ask or to tell, please contact Alexander Lukichev <alexander lukichev on gmail> You are welcome to contribute to this program, or do whatever you want with the source code (provided that you know what you are doing). Please respect the license if you change source code, see COPYING for details.