FramebufferUI 0.11.2

FBUI is a small, in-kernel graphical user interface for Linux. It permits you to put windows in each framebuffer-based virtual console, to read keyboard input, track a mouse pointer, and respond to typical GUI events. Each process may have more than one window.
- FBUI exists 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, 32 kilobyte driver which for some purposes may be quite sufficient. Liberation from bloat is desirable for a number of reasons that I explain in the Philosophy section.
- FBUI exists to assists 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 too primitive. FBUI is "just right", and libfbui makes using FBUI even easier to use by providing abstractions and additional functions.
- 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, 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 graphics UI driver where it belongs: inside the kernel with all the other drivers.
Main features:
- Unlike X Windows, FBUI supports windows on every virtual console.
- Each program may have more than one window.
- Overlapping windows are currently not supported, but I am adding support for them now.
- There is no concept of parent and child 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 Ive written are also designed to run in standalone mode, examples being fbcalc, fbview, fbscribble, and the my FBUI variant of mpeg2decode.
- Im providing a fairly basic window manager fbwm, but current development is centered on fbpm, which is my panel-based window manager.
FBUI offers a sufficient set of drawing routines:
- draw point, line, horizontal line, vertical line, rectangle
- draw text (8-bit)
- window clear, fill rectangle, clear rectangle
- copy area
- put pixels (3-byte RGB, and 4-byte (unsigned long) RGB, and native)
- 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
- FBUI is currently written for 8,16,24, and 32-bit directcolor and truecolor. I am presently adding 4-bpp VGA. (Note : on VESA, Ive done testing for 24 bit only.)
Sample programs provided (I suppose Ive 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