FBDirectOnConsoleLCD

=Intro=

Oh... one quick one... before we start here, I'm going to assume that you have a working Linux box with the latest GumStix build. You can find information about how to download and compile the canonical GumStix codebase by looking at the Getting The ConsoleLCD-VX Working page or the Buildroot page at GumStix' Wiki.

Specifically... I'm going to assume that you have a working environment for cross compiling. Once you've compiled gcc to be a cross-compiler, you setup the environment as described in the GumStix Programming page and use the command  to compile with. Actually... there's a cross-compiling version of all of the dev tools in the  directory, so including it in your path is probably a good idea. Here's a brief shell script I have that sets up the environment... you should change the value of  to reflect where you installed the gumstix source.

If you source this from the command line after you login, this should setup your environment to allow you to use the arm-linux-gcc command.

=Does the Frame Buffer Device Work?=

Well... this is a pretty simple question to answer... Yes, the frame buffer works, otherwise we wouldn't get the GumStix logo on the screen after booting. But I figured it might be prudent to spend a little time verifying that it works the way I think it's supposed to work.

Getting Frame Buffer Info
You can get information about the frame buffer via the command line by looking at the pseudo-files available in the directory:

For instance, if you wanted to know the size of the screen and the bits per pixel, you could cat two of the files in the directory like this:

Drawing Stuff on the Screen By Writing to /dev/fb0
Here's some code I wrote to exercise the frame buffer device. You can see the results on episode 2 of the hbmobile vlog.

When you want to draw stuff on the screen, you take the following steps:


 * 1) Include the appropriate headers
 * 2) Open the "/dev/fb0" device file
 * 3) Use the   syscall to get information about the device
 * 4) Use   to map the frame buffer into your process' memory space
 * 5) Poke pixels into screen memory

You can download a tar file with this code (which is released under a BSD style license) and a Makefile to help compile it.

Include Headers, Create a main, Yadda, Yadda, Yadda
So one of the things you can see that I do is I made an "App" data structure that's supposed to store the state of the application. You don't have to do this, I just thought it made things a little easier to deal with.

The most important part of the following code fragment is that it lists the headers you're supposed to use.

Initializing Things
For my money, this is where the most interesting stuff relating to frame buffer access occurs.. and it's not really that interesting. It's just boilerplate code.

Clearing the Screen
This code demonstrates simple access to the screen. We put a 0xFF in every byte in the frame buffer. It's pretty straight forward...

Drawing a Rainbow
This code shows how I draw a rainbow pattern.

Cleaning Up
Before we quit, we unmap the screen and close the device file. I think that Linux is smart enough to do this automagically when your process quits, but hey, it's always polite to explicitly tell the system your intentions.

=Does DirectFB Work on your Desktop Linux?=

After spending a bit of time trying to get DirectFB to work on the GumStix platform (and getting strange results,) I thought I would make sure I understand how it's supposed to work on a Desktop x86 system. So, to get DirectFB to work with the image we created on the VMWareImage page, we follow these steps.

Install PNG, JPEG, and FreeType2 Libraries
Execute the command:""

Download the DirectFB source
Download version 1.1.0 of the DirectFB source by going to the web site and downloading it through your browser, or by executing the following commands:""