As you already know, a frame buffer device is a memory device like
/dev/mem and it has the same features. You can read it, write it, seek
to some location in it and
mmap() it (the main usage). The difference
is just that the memory that appears in the special file is not the whole
memory, but the frame buffer of some video hardware.
/dev/fb* also allows several ioctls on it, by which lots of
information about the hardware can be queried and set. The color map handling
works via ioctls, too. Look into
<linux/fb.h> for more
information on what ioctls exist and on which data structures they work. Here's
just a brief overview:
EINVALif that isn't possible).
All this hardware abstraction makes the implementation of application programs easier and more portable. E.g. the X server works completely on /dev/fb* and thus doesn't need to know, for example, how the color registers of the concrete hardware are organized. XF68_FBDev is a general X server for bitmapped, unaccelerated video hardware. The only thing that has to be built into application programs is the screen organization (bitplanes or chunky pixels etc.), because it works on the frame buffer image data directly.
For the future it is planned that frame buffer drivers for graphics cards and the like can be implemented as kernel modules that are loaded at runtime. Such a driver just has to call register_framebuffer() and supply some functions. Writing and distributing such drivers independently from the kernel will save much trouble...