Framebuffer UI (fbui)
Copyright © 2004-2008 by Zack Smith.
All rights reserved.

Introduction

FBUI, or FrameBufferUI, is a small, in-kernel graphical user interface for Linux. It works only with kernel 2.6.9.

A summary of its key features:

  • It is very small, about 50kB.
  • It lives inside the Linux kernel, which places a natural limit on GUI bloat.
  • It permits multiple programs to share the framebuffer by letting each have graphical windows.
  • Each program may have multiple windows.
  • Windows may overlap, and be moved, resized, raised, lowered etc.
  • There can be windows on each virtual console.
  • Program interaction with FBUI is via a small set of system calls (ioctls).
  • Drawing primitives now support transparency.
  • It includes a small library libfbui to make using FBUI easier, and it includes an image-manipulation library and a font library.

Goals

  • FBUI exists firstly to reduce the software bloat that plagues modern operating systems. It does this by virtue of its being a simple windowing system in the form of a small, 50 kilobyte driver, which for many purposes and many users may be perfectly sufficient. Liberation from bloat is desirable for a number of reasons that I explain in the Philosophy section.
  • FBUI exists to assist people who are prohibited from using X Windows because they are using resource-limited platforms such as old computers and embedded devices. On these, X is an impossible burden. However a vanilla framebuffer is often far too primitive. FBUI is "just right", and libfbui makes using FBUI even easier to use by providing abstractions and additional functions. Note, FBUI is also a delight to use on faster computers.
  • FBUI exists to correct a flaw in the Linux operating system architecture. The traditional GUI -- X Windows -- is unlike any other subsystem of Linux in that the hardware-accelerated video drivers it uses are located within the X server, which is outside the kernel. Notice: normally Linux drivers and vital subsystems such as keyboard, USB, filesystem, serial I/O, et cetera are all located inside the kernel. FBUI simply puts the windowing system where it belongs: inside the kernel with all the other drivers.
  • FBUI can provide a means to use all of video memory, which on modern systems can be as much as 1024 megabytes (the eVGA Geforce 7950CX2). An OS like Linux is simply not designed to make that much video memory available to userspace with 32-bit addressing. When managed from within the kernel however, it can be accessed in pages and the entirely of it can be used to store all sorts of graphics data, including window data, fonts, et cetera.
  • It's conceivable that FBUI could be the basis for a desktop Linux focused on using older computers. This is assuming that 3D graphics will not become an emphasis.

Dealing With Superstition

Some would say, "But Microsoft tried the in-kernel graphics thing, and look what a mess it is!"

It is true that (A) Microsoft's pre-XP OSes were not stable or well designed and (B) Microsoft has used an in-kernel GUI approach. But to assume that B implies A is poor reasoning, as is the assumption that any such implication is valid for other developers. Such bad reasoning or superstition ignores the true causes of Microsoft's failures, which are:

  1. Microsoft project managers and/or programmers have proven themselves to be poor at more than just creating stable operating systems, which suggests poor project management or design, and/or poor coding and/or insufficient testing.
  2. Microsoft mainly borrows its idea from others, and anyone who merely copies others' work is bound to make mistakes due to lack of understanding.
  3. Microsoft has a different goal than I do in creating FBUI: their goal is money, whereas my goal is to create an effective and efficient software subsystem in the smallest possible size. History is littered with examples of companies that operated purely by the profit motive and who cut corners or skipped necessary steps, leading to disaster.
  4. Microsoft's windowing system is, like X Windows, a big, bloated piece of software and as every engineer knows, the larger and more complex a system or subsystem is, the more likely it is that there will be bugs.

Philosophy

Liberation from Bloat

FBUI's most important role in my opinion is the reduction of software bloat. Why make a fuss about bloat? Software bloat is bad because:

  • Software bloat keeps us all on the treadmill of always buying new hardware, which ultimately new software makes painfully slow, thus we are always falling behind. But the software makes the system slow because it is poorly designed and poorly implemented and rushed work, with the frequent consequence that it is bloated. Thus the purchasing-treadmill is economically and materially wasteful. It profits the few while making the many suffer unnecessarily.

  • Bloat is also bad for the Environment (which we live in and rely upon) since the manufacture of computer equipment involves the use of numerous very nasty chemicals which inevitably end up in the soil, water and air. Similarly the disposal of electronics results in chemicals leaching out of circuit boards, LCDs (which contain mercury) et cetera, which then enter the biosphere. We cannot afford to pretend this problem doesn't exist and we cannot afford to leave it to self-serving politicians to solve. It is better to solve the problem at the source: buy less hardware. (Article)

  • Liberation from bloat is liberation from rushed work, poorly managed projects, and bad engineering. It is liberation from those project managers and programmers who, rather than produce better, leaner, less buggy software, pass on the consequences of their bad choice to users who must pay to upgrade their hardware to accommodate the bloat. And as that software gets bigger and bulk is piled upon bulk, increasing numbers of bugs and vulnerabilities arise which require, you guessed it, more upgrades.

Windowing as a kind of hardware-like multiplexing

One of the underlying concepts and motivations for FBUI is the idea that a window can be viewed like a piece of hardware : a set of physical pixels. In this sense, the OS just does what it minimally should: it multiplexes access to the (abstract) hardware items, i.e. windows. This is a key reason why FBUI belongs in the kernel, because the bare minimum that a kernel should do is multiplex access to hardware. Even exokernels, which place every driver in userspace, are considered multiplexers.

In the kernel, you say?

Yes. Besides limiting GUI bloat, it also minimizes the interface to the simple and elegant ioctl interface.

You could have a GUI right from boot time, as the Enhanced Functionality module demonstrates with its simple line-drawing pattern: As soon as the penguin appears, you have EF graphics appearing.

FBUI could be improved so as to entirely replace the framebuffer device and framebuffer console so that you could never deal with any of that.

FBUI could provide the basis for a completely graphical startup à la Macintosh.

Comparison

Item FBUI 0.11.0
(in kB) 		X-Windows / XFree86 (in kB)
Core software ~50 1710
Library software ~30 1370 (that's just Xlib; required)
Panel-style window manager program 46½ (fbpm, static link) not available
Conventional window manager 41 (fbwm*, static link) 145 (twm, dynamic link)
Terminal emulator program 73 (fbterm, static link) 247 (xterm, dynamic link)
Analog clock program size 43½ (fbclock, static link) 29 (xclock, dynamic link)
Simple calculator program size 43½ (fbcalc, static link) ? (xcalc, dynamic link)
JPEG/TIFF viewer 60 (fbview, static link) 962 (xv, dynamic link)

* - Note, fbwm and fbpm are not fully functional software. They are works in progress.

Screenshots

The following are from the previous version of FBUI.


Screenshot while running fbpm
Screenshot while playing mpeg

Screenshot from an older version, running fbwm 		 

Features

  • Since there is no large server to start, individual programs start up instantaneously, as they did for instance under MSDOS.
  • Unlike X Windows, FBUI supports windows on every virtual console. Switching between consoles is fast.
  • Each program may have more than one window.
  • FBUI 0.11 supports overlapping windows.
  • Programs can receive raw keystrokes from FBUI which they can then translate to ASCII using a library routine. One process is permitted to have keyboard focus.
  • Each process accesses its windows completely independently of all other processes. In X, the library has to send all drawing commands to the server process, which puts them in a queue and executes them whenever it has a chance. If the server is busy, or another X application is flooding the queue, then an X application must wait. Not so with FBUI, where the ioctl takes a list of drawing commands that go directly to be executed if the window is visible and irregardless of what any other window is doing. To further ensure the above concurrency is the norm, use of semaphores within FBUI to access common data is made as brief as possible.
  • Each virtual console can have its own optional window manager process. But this is not necessary and for instance many programs that I've written are also designed to run as the only window on the display, examples being fbview, fbcalc, fbscribble, and the my FBUI variant of mpeg2decode.
  • I'm providing a very simple window manager fbwm, plus a panel-based manager fbpm, which organizes the display space for effecient work and play.
  • FBUI offers a good set of drawing routines:
    • draw point, line, horizontal line, vertical line, rectangle
    • window clear, fill rectangle, clear rectangle
    • copy area
    • triangle fill.
    • put pixels (2-byte RGB, 3-byte RGB, 4-byte (unsigned long) RGB, monochrome 1bpp, and 4-byte RGB + transparency)
    • wait for event
    • poll for event
    • the window manager process can hide and unhide other processes' windows, move, resize, re-expose, and delete windows.
    • read point
    • etc.
  • FBUI is currently written for 16,24, and 32-bit RGB displays, particularly VESA. I may add 4-bit VGA later.
  • Sample programs provided (I suppose I've gotten carried away) :
    • panel-based window manager (current focus of work)
    • conventional window manager
    • JPEG+TIFF image viewer
    • very simple MPEG playback based on circa 1995 MPEG2 library
    • terminal emulator (based on ggiterm)
    • load monitor
    • "scribbler" drawing program
    • analog clock
    • simple calculator
    • "Start" button program, which invokes fblauncher menu program
    • POP3 mail checker
    • "to do list" displayer program

Future Features

There are some features that would be nice to add if someone wants to work on them include the following. This list results from my doing an online poll. These were voted as being most desirable.

  • Overlay window support: This could be cheap to implement since the window logic is very minimal and the low-level code will be in the underlying driver.
  • Anti-aliased fonts in libfbui: This is, I think, a very interesting idea but there is the question of how much bloat this will add to libfbui. T1lib with X support is very roughly 250kB, and FreeType is much larger. I believe removing X support from the .a files should slim them down quite a bit. But if ultimately T1lib and FT are too large, I think I will instead add a TeX font reader.
  • 3D functions: This requires extended study on my part to see whether it is feasible or even desirable.

    Keep in mind that documentation for most serious 3D hardware is not available to the public anyway, no doubt because manufacturers are infringing one another's patents. For those cards that we can get data sheets for, funneling 3D instructions and data through FBUI may be possible, but (A) the cost in bloat may be unacceptable, and (B) there may be better ways to do 3D, such as in software e.g. using Mesa.

    In the meantime, for novelty's sake, I've coded a triangle-fill routine and I have included it in FBUI 0.11.

  • Widgets: I'm cobbling together a set of basic widgets to add to libfbui, however someone might want to port FLTK2.

Mailing List

Finally, there is a mailing list http://groups.yahoo.com/group/fbui/. Post message: fbui@yahoogroups.com
Subscribe: fbui-subscribe@yahoogroups.com

Live CD

Dusan Halicky has produced an FBUI/Linux Live CD that demonstrates very clearly how effective FBUI is. Simply use his ISO to create a bootable CD and boot it. You can run FBUI programs immediately after logging in. I've tested it on two systems (Toshiba A105 with USB mouse, and a Dell PIII/700 desktop) and found it worked very well. Find it here: vdl.halicky.sk/fbui/. I suggest that after logging in you run fbterm, and then fbpm in the background followed by other programs e.g. fbcalc.

Project status

Inclusion of FBUI into the Linux kernel has been blocked by the framebuffer device group, however that doesn't mean that FBUI could not replace the framebuffer device. That would be a fairly large undertaking.

I'm presently developing a userspace equivalent to FBUI, tentatively called FWE (Frugal Windowing Environment). I have the same basic goals in developing FWE as I did with FBUI.

More information about FWE is here.

Download

Note:   FBUI requires kernel 2.6.9. Subsequent versions of the framebuffer code, which other people wrote, have proven to have too many bugs and/or design problems to permit using FBUI with them.

Code Status: alpha
Send bug reports via the email address below. 

cd /usr/src/linux
cp ... fbui*.tar.bz2
tar jxfv fbui*.tar.bz2

I also created a patch for kernel 2.15.4 that implements part of FBUI: EF.

Installation for Non-Programmers

  1. FBUI resides inside the 2.6.9 kernel, so the first thing you must do is to get the kernel, un-tar FBUI in its directory, select the necessary options mentioned in the README, then make the kernel and update your loader to let you boot the new kernel. (I will offer a precompiled x86 kernel later.)
  2. You also need to tell your boot loader to switch to the VESA console during booting. In LILO use the expression vga=792 for a 1024x768 display or vga=789 for 800x600.
  3. Then you boot with the kernel. Next you need to set up the PCF font directory, populating it with fonts from the X distribution, making sure to uncompress them. The PCF font reader is really just a temporary chunk of code so I'm not going to update it to perform automatic decompression. Note, if you aren't sure where the fonts are, type (as root) find / -name "*.pcf*". To make sure libfbui knows where they are, you can use the PCFFONTDIR environment variable (as in export PCFFONTDIR=/path...).
  4. Once you've done these things, just compile the sample programs in /usr/src/linux-2.6.9/libfbui and run them from there. You may find it helps to run a program in a different virtual console using the -c switch.

Contact

eXTReMe Tracker

Links