Shell Person Help me keep the shell people alive.


The Trouble with the Framebuffer

The original plan

I've tried for a long time to have a usable, console-only, desktop linux system.  By console-only, I mean running without (a.k.a. X).  I thought the key to this would be using the framebuffer.  Here's wikipedia's definition of the framebuffer, but in short it allows displaying graphics without running X.  When the framebuffer is enabled (some systems enable it by default), the first thing you notice is that the console font is smaller and nicer.  This alone makes the console considerably more usable, as the screen doesn't scroll nearly as much, letting you see more at once.  However, that's not all you can do with the framebuffer.  You can also view PDFs, images, and video (using mplayer) with the framebuffer, and even compile complex programs to use the framebuffer instead of X (i.e. gimp, using GTK-DFB).

The main thing that stood in the way of my console-only desktop system is a modern browser.  Now supposedly Firefox has been compiled for the framebuffer, as has uzbl.  However, I've had no luck with either, and I've sunk a fair amount of time into the task.  And links-g just doesn't cut it for me.

The original assumption

One of the reasons I wanted a console-only system was for the speed.  I began using linux (a little over 5 years ago) with Ubuntu.  With each new release I tried, it seemed like the system got slower and slower.  However, after installing a server edition of Ubuntu, with no desktop environment, and no X, I experienced the speed of a console-only system (and the really nice boot-time).  I assumed that it was X that was holding back Ubuntu on my laptop.  This assumption was reinforced by lots of negative comments about X (a lot of people online like to complain about it).

Why I'm really glad I failed

I gave up on my console-only, framebuffer, desktop system, and I'm really glad that I did.  I installed bare-bones Debian Stable (using the netinst cd), then installed X and the ratpoison window manager, and haven't looked back since.  It turns out that my assumption that X was slowing me down was wrong -- in fact, on my hardware I get better performance from X than I did with the framebuffer.  This is immediately evident when large amounts of text scrolls down the screen (which is noticeably slow in the framebuffer), but also evident when trying to play movies in the framebuffer.  If I had to guess, I'd say that it was GNOME that was slowing me down, and in particular it was Ubuntu's (and Debian's) implementation of GNOME (I've heard that GNOME can be fast).

Now I have a system that

  • Boots fast
  • Runs fast
  • Acts like a console-only, framebuffer system (the machine boots to a white-text-on-black-background fullscreen terminal)
  • Plays video (better than in the framebuffer)
  • and runs Firefox 3.6.3 (fast), with Flash (for hulu, youtube, etc.)

In short, it's pretty much the perfect system for me.  I do almost everything in the terminal, but also have a modern browser at my fingertips.  Also, controlling ratpoison is a lot like controlling GNU screen (which I still also use).

Comments (5) Trackbacks (0)
  1. i was considering a cli/framebuffer combo for my system. but reading about your experiences confirmed what i expected for a long time. it’s not x, it’s ubuntu.

  2. Yeah, if you’re into minimalism, I highly recommend ratpoison on a bare system. I’m using Debian, and even though I find GNOME in Debian slow, I have no speed problems at all with ratpoison. (And Debian’s so easy. You can almost certainly coax more speed out of Arch, but I’ve come to really love Debian’s ease).

  3. If you like ratpoision, try xmonad as well. Personally, I prefer ratpoison,
    but it’s good to see what else is out there.

    I enjoy using my virtual terminals for everything non-graphical, which is a
    lot for a unix-head like me. But I’m having a contrasting experience from
    yours. I’m driven away from the VTs *because* of the framebuffer. It’s too
    slow to scroll and I haven’t yet figured out the proper way to disable the
    framebuffer. (It’s on by default with the latest Debian-unstable with KMS.)

  4. Hi Ben, I’m assuming that Unstable is using Grub2 now, right? Disabling the framebuffer in Grub1 was pretty easy (and I’m still using Grub1 w/ Lenny). My unconfirmed advice is that you’ll have to disable it by editing /etc/default/grub and /etc/grub.d/00_header

    I found the instructions at but I haven’t tested them myself. Good luck.

  5. Yes – the performance issues of late model linux distrubutions can be diminished with a minimalist window manager. However – the performance issues with bloated applications that rely on X and Gnome features are still a problem. Like you, I’ve used minimalist window managers to alleviate the problem. It helps a lot, but I’ve found something that works better for me.

    The Netsurf framebuffer browser is the fastest I’ve used. This is not necesarily a framebuffer vs. X issue, but may be majorly something that results from a browser devoid of internal cruft – and designed with a very quick layout and rendering engine.

    I should modify this context to say that I often use antiuqe hardware, which would provide relatively poor X performance no matter what the application software. With the latest and greatest hardware, things would be different. I think Netsurf framebuffer version is well situated for some of these ARM Soc offerings (Raspberry Pi, Beaglebone, Odroid-Xu, etc). I think I’ve read other blogs containing praise for Netsurf on Pi. I haven’t considered the idea of security at all – as related to the use of framebuffers and the Netsurf browser. That’s another, separate thing to consider.

Leave a comment

No trackbacks yet.