Framebuffer Intro Next page:
    Writing Pixels
Although the Qtopia environment allows very advanced applications to be produced, the work I am doing on GNU Smalltalk requires full access to the screen. This means that I need to handle the framebuffer. The PMA430 framebuffer is easy to access and standard methods of getting the information and mapping the device to memory work. Up to a point. An example application I wrote extracts some useful data and displays it. To try this, save it and compile using: 
arm-linux-gcc -o fbinfo fbinfo.c
A compiled version is available here: When copied onto a PMA430 and run (from a terminal window), the output should be: 
ID: DM270_OSD, len:77824
Framebuffer type 0: packed pixels
Framebuffer visual 3: pseudo colour
line len: 320, accel: 0
xres: 320, yres: 240, xoff: 0, yoff: 0
bits per pixel: 8
      Offset Length MSBR
red        0      8  0
green      0      8  0
blue       0      8  0
transp     0      0  0
screen size: 76800
screen mapped successfully
What this means is that the physical framebuffer starts at the beginning of the physically mapped device (no offsets), has a horizontal resolution of 320 pixels and a vertical resolution of 240 pixels. There are 8 bits per pixel, so each pixel is represented by 1 byte, hence the scan lines are 320 bytes long and the physical framebuffer to map is 76800 bytes. The actual framebuffer size is 77824 bytes so there is an extra 1k of storage in the framebuffer that is not mapped to the screen. I haven't looked at this area yet.

Note that the framebuffer is a pseudo colour device, so each location is an index into the device's colourmap. The colour offsets are, therefore, meaningless, however there appears to be no transparancy defined. The following program will display the colourmap and generate a file containing the RGB values for the default map.

Compile as before. A pre-compiled version is available: When run, this will fill the screen with the current colourmap. If this is the default, then you should see that the first square (colour 0) is full of random colour. I don't know at the moment when this represents. The colourmap values are the same as those for colour 1 (black). Colours 1 through 216 represent a 6x6x6 colour cube ending in white. You will then see a 16 tone grey scale followed by a number of specified colours ending in white at colour 255. The application will exit when you enter a key (if you are not using a keyboard, then the "play/pause" key can be used as this is read as "return"). The screen will be restored to it's previous contents.

The RGB values for the colourmap will be written into the file /tmp/cmap.txt. A copy is available for you to view (the values are in hex):

These colour values will be adequate for ordinary applications, however if you have an application which requires very specific colour values, you'll have to change the colourmap.

  Framebuffer Intro Next page:
    Writing Pixels