<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Programmer's View of /dev/fb*</TITLE>
</HEAD>
<BODY BGCOLOR="#efefef" TEXT="black" LINK="blue" VLINK="#551A8B" ALINK="red">

<A HREF="fbdev.html"><EM>The Linux/m68k Frame Buffer Device</EM></A>
 <b>:</b> <EM>Programmer's View of <code>/dev/fb*</code></EM><BR>
<b>Previous:</b> <A HREF="fbdev2.html"><EM>User's View of <code>/dev/fb*</code></EM></A><BR>
<b>Next:</b> <A HREF="fbdev4.html"><EM>Frame Buffer Resolution Maintenance</EM></A>


<HR NOSHADE>
  <H2><A NAME="3"></A>3. Programmer's View of <code>/dev/fb*</code></H2>
<p>As you already know, a frame buffer device is a memory device like
<code>/dev/mem</code> and it has the same features. You can read it, write it, seek
to some location in it and <code>mmap()</code> 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.</p>
<p><code>/dev/fb*</code> 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 <code>&lt;linux/fb.h&gt;</code> for more
information on what ioctls exist and on which data structures they work. Here's
just a brief overview:</p>
<p>
<ul>
<li>You can request unchangeable information about the hardware, like
name, organization of the screen memory (planes, packed pixels, ...) and
address and length of the screen memory.
</li>
<li>You can request and change variable information about the hardware,
like visible and virtual geometry, depth, color map format, timing, and so
on.  If you try to change that informations, the driver maybe will round up
some values to meet the hardware's capabilities (or return <code>EINVAL</code>
if that isn't possible).
</li>
<li>You can get and set parts of the color map. Communication is done
with 16 bit per color part (red, green, blue, transparency) to support all
existing hardware. The driver does all the computations needed to bring it
into the hardware (round it down to less bits, maybe throw away
transparency).</li>
</ul>
</p>
<p>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. <em>XF68_FBDev</em> 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.</p>
<p>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...</p>


 <HR NOSHADE>
<A HREF="fbdev.html"><EM>The Linux/m68k Frame Buffer Device</EM></A>
 <b>:</b> <EM>Programmer's View of <code>/dev/fb*</code></EM><BR>
<b>Previous:</b> <A HREF="fbdev2.html"><EM>User's View of <code>/dev/fb*</code></EM></A><BR>
<b>Next:</b> <A HREF="fbdev4.html"><EM>Frame Buffer Resolution Maintenance</EM></A>



</BODY>
</HTML>
