K.Mandla's blog of Linux experiences

A quick look at framebuffer applications

I use framebuffer-driven systems on a daily basis, but it’s rare for me to look beyond image viewers, screen grabbers or the occasional terminal font in terms of software written to take advantage of the framebuffer.

Personally I’ve never seen that mythical desktop built entirely around the framebuffer. I have been told it exists and I’ve seen some ancient screenshots, and it seems that some things, like Firefox 2 or a couple other programs, can be adjust to rely on it instead of the traditional X suite. I’d love to try it, but I’d love to try a lot of things, and I just don’t ever seem to have the time or resources. :(

But there are some obvious standbys: mplayer, for example, with the fbdev option for video out. Or links2 in it’s graphical form, which is a great way to surf without requiring a massive load of dependencies and still keep a visual element. zgv is often mentioned as an image viewer with framebuffer support.

Qingy is another good example. I used qingy on some Arch systems a long time ago, and what I remember was very promising. As it is though, I don’t usually need a login manager. I do that at the terminal prompt, and move on from there.

As far as framebuffer image grabbers, there are quite a few. I regularly use fbgrab on my Pentium, but I have seen fbshot, fbdump and fb2png in action as well. Which one you prefer will depend on your own tastes, coupled with your tolerance for the dependencies they draw; a couple of those have rather far-reaching demands.

The converse of those programs, the framebuffer image viewer, is likewise fairly prevalent. You probably have heard about the fbida suite, which has applications for image and PDF display. fbv is another, but for some reason it has never shown me anything but scrambled output. fim is one of my favorites, but in its latest incarnations I’ve had trouble building it. It’s still very much a work in progress.

For specific framebuffer tty work, look into fbset, fbgetty and fbterm. fbterm can be kind of fun; with the Debian version I was able to rotate the framebuffer 90 degrees and run the console at an angle. Why would you want to do that? I have no idea, but it was cool for a little while.

Three other small tools that you might find useful: Ali Gholami Rudi‘s fbff, fbpad and fbpdf. Ali mentioned these a long time ago and I dutifully tried them out and took notes. fbpdf, as you might imagine, displays PDF images, while fbpad is a framebuffer virtual terminal. fbff hooks audio and media playback through the ffmpeg libraries, which means you might get video playback on the framebuffer without relying on an enormous media player or a personalized rebuild. Judging by the updates on those git pages, Ali is actively working on those little applications too.

I think that’s about it for now. This is only a quick skim past what Debian-Ubuntu and Arch list among framebuffer-centered software, and I can vouch for just about everything that’s here. It’s by no means complete though. And if anybody out there is working from that mythical desktop rooted to the framebuffer, please let us know how you got there. ;)

Post navigation

12 thoughts on “A quick look at framebuffer applications”

Huh. I didn’t know xlinks2 could run on the framebuffer. You know, if you don’t have a convenient fb image viewer available, xlinks2 is actually not half bad at the task, especially since you can quickly browse directories with it. Well, if you don’t mind the lack of thumbnailing support.

Framebuffer is especially interesting coupled with KMS, which means nvidia users are shit out of luck at the moment, as KMS offers acceleratiion which neither uvesafb nor vesafb offer.
Still, I prefer directfb for all my framebuffer applications.
links2 and mplayer both can be built with directfb as backend.
directfb offers acceleration for pretty much every card and even has experimental opengl support, afaik currently still software mesa though unless you own a matrox.
SDL can be built with directfb as backend as well, so any app not using specific X extensions or such can be run on directfb as well.
Note also that export SDL_VIDEODRIVER=fbcon lets SDL use the standard /dev/fb0 for output :)
On Archlinux you can find gtk2-dfb pango-dfb and cairo-dfb in AUR which allow you to compile such apps, provided they do not use any weird X calls, for directfb, which is how firefix2 is built.
Cheers.

If I had a tft screen that can be rotated, I would love to be able
to rotate the framebuffer screen, too. At least with graphical desktops
I always enjoy being able to rotate the screen for reading pdf files
or when using Word at the University.

I realize this is an old post, but I think I’ve found at least two Linux distributions that meet the criteria of working mainly with the framebuffer. One is NanoLinux. It uses nano-x via framebuffer and has several applications based on FLTK and a few on X11 (actually nxlib). Using nano-x allows the distribution to leave out the X Windows dependencies. Another is Rogue Class Linux. It includes applications that use SDL built with a framebuffer back-end. I’ve also been looking into this subject and am trying to find useful applications that will replace most of my daily desktop tasks and work in framebuffer mode. I’ve been investigating using SDL and FLTK via DirectFB. I’ve put together a nice collection of applications that will run in framebuffer and have the scripts to build many of them from source, but could always use suggestions for other alternatives.