[linux-2.6-block.git] / Documentation / fb / framebuffer.rst

=======================
The Frame Buffer Device
=======================

Last revised: May 10, 2001


0. Introduction
---------------

The frame buffer device provides an abstraction for the graphics hardware. It
represents the frame buffer of some video hardware and allows application
software to access the graphics hardware through a well-defined interface, so
the software doesn't need to know anything about the low-level (hardware
register) stuff.

The device is accessed through special device nodes, usually located in the
/dev directory, i.e. /dev/fb*.


1. User's View of /dev/fb*
--------------------------

From the user's point of view, the frame buffer device looks just like any
other device in /dev. It's a character device using major 29; the minor
specifies the frame buffer number.

By convention, the following device nodes are used (numbers indicate the device
minor numbers)::

      0 = /dev/fb0	First frame buffer
      1 = /dev/fb1	Second frame buffer
	  ...
     31 = /dev/fb31	32nd frame buffer

For backwards compatibility, you may want to create the following symbolic
links::

    /dev/fb0current -> fb0
    /dev/fb1current -> fb1

and so on...

The frame buffer devices are also `normal` memory devices, this means, you can
read and write their contents. You can, for example, make a screen snapshot by::

  cp /dev/fb0 myfile

There also can be more than one frame buffer at a time, e.g. if you have a
graphics card in addition to the built-in hardware. The corresponding frame
buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.

Application software that uses the frame buffer device (e.g. the X server) will
use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
an alternative frame buffer device by setting the environment variable
$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
users)::

    export FRAMEBUFFER=/dev/fb1

or (for csh users)::

    setenv FRAMEBUFFER /dev/fb1

After this the X server will use the second frame buffer.


2. Programmer's View of /dev/fb*
--------------------------------

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:

  - 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.

  - 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 information, the driver maybe will round up some
    values to meet the hardware's capabilities (or return EINVAL if that isn't
    possible).

  - You can get and set parts of the color map. Communication is done with 16
    bits per color part (red, green, blue, transparency) to support all
    existing hardware. The driver does all the computations needed to apply
    it to the hardware (round it down to less bits, maybe throw away
    transparency).

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...


3. Frame Buffer Resolution Maintenance
--------------------------------------

Frame buffer resolutions are maintained using the utility `fbset`. It can
change the video mode properties of a frame buffer device. Its main usage is
to change the current video mode, e.g. during boot up in one of your `/etc/rc.*`
or `/etc/init.d/*` files.

Fbset uses a video mode database stored in a configuration file, so you can
easily add your own modes and refer to them with a simple identifier.


4. The X Server
---------------

The X server (XF68_FBDev) is the most notable application program for the frame
buffer device. Starting with XFree86 release 3.2, the X server is part of
XFree86 and has 2 modes:

  - If the `Display` subsection for the `fbdev` driver in the /etc/XF86Config
    file contains a::

	Modes "default"

    line, the X server will use the scheme discussed above, i.e. it will start
    up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
    still have to specify the color depth (using the Depth keyword) and virtual
    resolution (using the Virtual keyword) though. This is the default for the
    configuration file supplied with XFree86. It's the most simple
    configuration, but it has some limitations.

  - Therefore it's also possible to specify resolutions in the /etc/XF86Config
    file. This allows for on-the-fly resolution switching while retaining the
    same virtual desktop size. The frame buffer device that's used is still
    /dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
    defined by /etc/XF86Config now. The disadvantage is that you have to
    specify the timings in a different format (but `fbset -x` may help).

To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
work 100% with XF68_FBDev: the reported clock values are always incorrect.


5. Video Mode Timings
---------------------

A monitor draws an image on the screen by using an electron beam (3 electron
beams for color models, 1 electron beam for monochrome monitors). The front of
the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
is hit by an electron, it emits a photon and thus becomes visible.

The electron beam draws horizontal lines (scanlines) from left to right, and
from the top to the bottom of the screen. By modifying the intensity of the
electron beam, pixels with various colors and intensities can be shown.

After each scanline the electron beam has to move back to the left side of the
screen and to the next line: this is called the horizontal retrace. After the
whole screen (frame) was painted, the beam moves back to the upper left corner:
this is called the vertical retrace. During both the horizontal and vertical
retrace, the electron beam is turned off (blanked).

The speed at which the electron beam paints the pixels is determined by the
dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
of cycles per second), each pixel is 35242 ps (picoseconds) long::

    1/(28.37516E6 Hz) = 35.242E-9 s

If the screen resolution is 640x480, it will take::

    640*35.242E-9 s = 22.555E-6 s

to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
also takes time (e.g. 272 `pixels`), so a full scanline takes::

    (640+272)*35.242E-9 s = 32.141E-6 s

We'll say that the horizontal scanrate is about 31 kHz::

    1/(32.141E-6 s) = 31.113E3 Hz

A full screen counts 480 (yres) lines, but we have to consider the vertical
retrace too (e.g. 49 `lines`). So a full screen will take::

    (480+49)*32.141E-6 s = 17.002E-3 s

The vertical scanrate is about 59 Hz::

    1/(17.002E-3 s) = 58.815 Hz

This means the screen data is refreshed about 59 times per second. To have a
stable picture without visible flicker, VESA recommends a vertical scanrate of
at least 72 Hz. But the perceived flicker is very human dependent: some people
can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.

Since the monitor doesn't know when a new scanline starts, the graphics board
will supply a synchronization pulse (horizontal sync or hsync) for each
scanline.  Similarly it supplies a synchronization pulse (vertical sync or
vsync) for each new frame. The position of the image on the screen is
influenced by the moments at which the synchronization pulses occur.

The following picture summarizes all timings. The horizontal retrace time is
the sum of the left margin, the right margin and the hsync length, while the
vertical retrace time is the sum of the upper margin, the lower margin and the
vsync length::

  +----------+---------------------------------------------+----------+-------+
  |          |                ↑                            |          |       |
  |          |                |upper_margin                |          |       |
  |          |                ↓                            |          |       |
  +----------###############################################----------+-------+
  |          #                ↑                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |   left   #                |                            #  right   | hsync |
  |  margin  #                |       xres                 #  margin  |  len  |
  |<-------->#<---------------+--------------------------->#<-------->|<----->|
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |yres                        #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                |                            #          |       |
  |          #                ↓                            #          |       |
  +----------###############################################----------+-------+
  |          |                ↑                            |          |       |
  |          |                |lower_margin                |          |       |
  |          |                ↓                            |          |       |
  +----------+---------------------------------------------+----------+-------+
  |          |                ↑                            |          |       |
  |          |                |vsync_len                   |          |       |
  |          |                ↓                            |          |       |
  +----------+---------------------------------------------+----------+-------+

The frame buffer device expects all horizontal timings in number of dotclocks
(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.


6. Converting XFree86 timing values info frame buffer device timings
--------------------------------------------------------------------

An XFree86 mode line consists of the following fields::

 "800x600"     50      800  856  976 1040    600  637  643  666
 < name >     DCF       HR  SH1  SH2  HFL     VR  SV1  SV2  VFL

The frame buffer device uses the following fields:

  - pixclock: pixel clock in ps (pico seconds)
  - left_margin: time from sync to picture
  - right_margin: time from picture to sync
  - upper_margin: time from sync to picture
  - lower_margin: time from picture to sync
  - hsync_len: length of horizontal sync
  - vsync_len: length of vertical sync

1) Pixelclock:

   xfree: in MHz

   fb: in picoseconds (ps)

   pixclock = 1000000 / DCF

2) horizontal timings:

   left_margin = HFL - SH2

   right_margin = SH1 - HR

   hsync_len = SH2 - SH1

3) vertical timings:

   upper_margin = VFL - SV2

   lower_margin = SV1 - VR

   vsync_len = SV2 - SV1

Good examples for VESA timings can be found in the XFree86 source tree,
under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".


7. References
-------------

For more specific information about the frame buffer device and its
applications, please refer to the Linux-fbdev website:

    http://linux-fbdev.sourceforge.net/

and to the following documentation:

  - The manual pages for fbset: fbset(8), fb.modes(5)
  - The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
  - The mighty kernel sources:

      - linux/drivers/video/
      - linux/include/linux/fb.h
      - linux/include/video/


8. Mailing list
---------------

There is a frame buffer device related mailing list at kernel.org:
linux-fbdev@vger.kernel.org.

Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
subscription information and archive browsing.


9. Downloading
--------------

All necessary files can be found at

    ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/

and on its mirrors.

The latest version of fbset can be found at

    http://www.linux-fbdev.org/


10. Credits
-----------

This readme was written by Geert Uytterhoeven, partly based on the original
`X-framebuffer.README` by Roman Hodek and Martin Schaller. Section 6 was
provided by Frank Neumann.

The frame buffer device abstraction was designed by Martin Schaller.
Commit	Line	Data
ab42b818 MCC	1	=======================
	2	The Frame Buffer Device
	3	=======================
1da177e4	4
1da177e4 LT	5	Last revised: May 10, 2001
	6
	7
	8	0. Introduction
	9	---------------
	10
	11	The frame buffer device provides an abstraction for the graphics hardware. It
	12	represents the frame buffer of some video hardware and allows application
	13	software to access the graphics hardware through a well-defined interface, so
	14	the software doesn't need to know anything about the low-level (hardware
	15	register) stuff.
	16
	17	The device is accessed through special device nodes, usually located in the
	18	/dev directory, i.e. /dev/fb*.
	19
	20
	21	1. User's View of /dev/fb*
	22	--------------------------
	23
	24	From the user's point of view, the frame buffer device looks just like any
	25	other device in /dev. It's a character device using major 29; the minor
	26	specifies the frame buffer number.
	27
	28	By convention, the following device nodes are used (numbers indicate the device
ab42b818	29	minor numbers)::
1da177e4 LT	30
	31	0 = /dev/fb0 First frame buffer
	32	1 = /dev/fb1 Second frame buffer
	33	...
	34	31 = /dev/fb31 32nd frame buffer
	35
	36	For backwards compatibility, you may want to create the following symbolic
ab42b818	37	links::
1da177e4 LT	38
	39	/dev/fb0current -> fb0
	40	/dev/fb1current -> fb1
	41
	42	and so on...
	43
ab42b818 MCC	44	The frame buffer devices are also `normal` memory devices, this means, you can
ab42b818 MCC	45	read and write their contents. You can, for example, make a screen snapshot by::
1da177e4 LT	46
	47	cp /dev/fb0 myfile
	48
	49	There also can be more than one frame buffer at a time, e.g. if you have a
	50	graphics card in addition to the built-in hardware. The corresponding frame
	51	buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.
	52
	53	Application software that uses the frame buffer device (e.g. the X server) will
	54	use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
	55	an alternative frame buffer device by setting the environment variable
	56	$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
ab42b818	57	users)::
1da177e4 LT	58
	59	export FRAMEBUFFER=/dev/fb1
	60
ab42b818	61	or (for csh users)::
1da177e4 LT	62
	63	setenv FRAMEBUFFER /dev/fb1
	64
	65	After this the X server will use the second frame buffer.
	66
	67
	68	2. Programmer's View of /dev/fb*
	69	--------------------------------
	70
	71	As you already know, a frame buffer device is a memory device like /dev/mem and
	72	it has the same features. You can read it, write it, seek to some location in
	73	it and mmap() it (the main usage). The difference is just that the memory that
	74	appears in the special file is not the whole memory, but the frame buffer of
	75	some video hardware.
	76
	77	/dev/fb* also allows several ioctls on it, by which lots of information about
	78	the hardware can be queried and set. The color map handling works via ioctls,
	79	too. Look into <linux/fb.h> for more information on what ioctls exist and on
	80	which data structures they work. Here's just a brief overview:
	81
	82	- You can request unchangeable information about the hardware, like name,
	83	organization of the screen memory (planes, packed pixels, ...) and address
	84	and length of the screen memory.
	85
	86	- You can request and change variable information about the hardware, like
	87	visible and virtual geometry, depth, color map format, timing, and so on.
	88	If you try to change that information, the driver maybe will round up some
	89	values to meet the hardware's capabilities (or return EINVAL if that isn't
	90	possible).
	91
	92	- You can get and set parts of the color map. Communication is done with 16
ab42b818 MCC	93	bits per color part (red, green, blue, transparency) to support all
	94	existing hardware. The driver does all the computations needed to apply
	95	it to the hardware (round it down to less bits, maybe throw away
1da177e4 LT	96	transparency).
	97
	98	All this hardware abstraction makes the implementation of application programs
	99	easier and more portable. E.g. the X server works completely on /dev/fb* and
	100	thus doesn't need to know, for example, how the color registers of the concrete
	101	hardware are organized. XF68_FBDev is a general X server for bitmapped,
	102	unaccelerated video hardware. The only thing that has to be built into
	103	application programs is the screen organization (bitplanes or chunky pixels
	104	etc.), because it works on the frame buffer image data directly.
	105
	106	For the future it is planned that frame buffer drivers for graphics cards and
	107	the like can be implemented as kernel modules that are loaded at runtime. Such
	108	a driver just has to call register_framebuffer() and supply some functions.
	109	Writing and distributing such drivers independently from the kernel will save
	110	much trouble...
	111
	112
	113	3. Frame Buffer Resolution Maintenance
	114	--------------------------------------
	115
ab42b818	116	Frame buffer resolutions are maintained using the utility `fbset`. It can
1da177e4	117	change the video mode properties of a frame buffer device. Its main usage is
ab42b818 MCC	118	to change the current video mode, e.g. during boot up in one of your `/etc/rc.*`
ab42b818 MCC	119	or `/etc/init.d/*` files.
1da177e4 LT	120
	121	Fbset uses a video mode database stored in a configuration file, so you can
	122	easily add your own modes and refer to them with a simple identifier.
	123
	124
	125	4. The X Server
	126	---------------
	127
	128	The X server (XF68_FBDev) is the most notable application program for the frame
	129	buffer device. Starting with XFree86 release 3.2, the X server is part of
	130	XFree86 and has 2 modes:
	131
ab42b818 MCC	132	- If the `Display` subsection for the `fbdev` driver in the /etc/XF86Config
ab42b818 MCC	133	file contains a::
1da177e4 LT	134
	135	Modes "default"
	136
	137	line, the X server will use the scheme discussed above, i.e. it will start
	138	up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
	139	still have to specify the color depth (using the Depth keyword) and virtual
	140	resolution (using the Virtual keyword) though. This is the default for the
	141	configuration file supplied with XFree86. It's the most simple
	142	configuration, but it has some limitations.
	143
	144	- Therefore it's also possible to specify resolutions in the /etc/XF86Config
	145	file. This allows for on-the-fly resolution switching while retaining the
	146	same virtual desktop size. The frame buffer device that's used is still
	147	/dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
	148	defined by /etc/XF86Config now. The disadvantage is that you have to
ab42b818	149	specify the timings in a different format (but `fbset -x` may help).
1da177e4 LT	150
	151	To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
	152	work 100% with XF68_FBDev: the reported clock values are always incorrect.
	153
	154
	155	5. Video Mode Timings
	156	---------------------
	157
	158	A monitor draws an image on the screen by using an electron beam (3 electron
	159	beams for color models, 1 electron beam for monochrome monitors). The front of
	160	the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
	161	is hit by an electron, it emits a photon and thus becomes visible.
	162
	163	The electron beam draws horizontal lines (scanlines) from left to right, and
	164	from the top to the bottom of the screen. By modifying the intensity of the
	165	electron beam, pixels with various colors and intensities can be shown.
	166
	167	After each scanline the electron beam has to move back to the left side of the
	168	screen and to the next line: this is called the horizontal retrace. After the
	169	whole screen (frame) was painted, the beam moves back to the upper left corner:
	170	this is called the vertical retrace. During both the horizontal and vertical
	171	retrace, the electron beam is turned off (blanked).
	172
	173	The speed at which the electron beam paints the pixels is determined by the
	174	dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
ab42b818	175	of cycles per second), each pixel is 35242 ps (picoseconds) long::
1da177e4 LT	176
	177	1/(28.37516E6 Hz) = 35.242E-9 s
	178
ab42b818	179	If the screen resolution is 640x480, it will take::
1da177e4 LT	180
	181	640*35.242E-9 s = 22.555E-6 s
	182
	183	to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
ab42b818	184	also takes time (e.g. 272 `pixels`), so a full scanline takes::
1da177e4 LT	185
	186	(640+272)*35.242E-9 s = 32.141E-6 s
	187
ab42b818	188	We'll say that the horizontal scanrate is about 31 kHz::
1da177e4 LT	189
	190	1/(32.141E-6 s) = 31.113E3 Hz
	191
	192	A full screen counts 480 (yres) lines, but we have to consider the vertical
ab42b818	193	retrace too (e.g. 49 `lines`). So a full screen will take::
1da177e4 LT	194
	195	(480+49)*32.141E-6 s = 17.002E-3 s
	196
ab42b818	197	The vertical scanrate is about 59 Hz::
1da177e4 LT	198
	199	1/(17.002E-3 s) = 58.815 Hz
	200
	201	This means the screen data is refreshed about 59 times per second. To have a
	202	stable picture without visible flicker, VESA recommends a vertical scanrate of
	203	at least 72 Hz. But the perceived flicker is very human dependent: some people
	204	can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
	205
	206	Since the monitor doesn't know when a new scanline starts, the graphics board
	207	will supply a synchronization pulse (horizontal sync or hsync) for each
	208	scanline. Similarly it supplies a synchronization pulse (vertical sync or
	209	vsync) for each new frame. The position of the image on the screen is
	210	influenced by the moments at which the synchronization pulses occur.
	211
	212	The following picture summarizes all timings. The horizontal retrace time is
	213	the sum of the left margin, the right margin and the hsync length, while the
	214	vertical retrace time is the sum of the upper margin, the lower margin and the
ab42b818	215	vsync length::
1da177e4 LT	216
1da177e4 LT	217	+----------+---------------------------------------------+----------+-------+
be2a608b	218	\| \| ↑ \| \| \|
1da177e4	219	\| \| \|upper_margin \| \| \|
be2a608b	220	\| \| ↓ \| \| \|
1da177e4	221	+----------###############################################----------+-------+
be2a608b	222	\| # ↑ # \| \|
1da177e4 LT	223	\| # \| # \| \|
	224	\| # \| # \| \|
	225	\| # \| # \| \|
	226	\| left # \| # right \| hsync \|
	227	\| margin # \| xres # margin \| len \|
	228	\|<-------->#<---------------+--------------------------->#<-------->\|<----->\|
	229	\| # \| # \| \|
	230	\| # \| # \| \|
	231	\| # \| # \| \|
	232	\| # \|yres # \| \|
	233	\| # \| # \| \|
	234	\| # \| # \| \|
	235	\| # \| # \| \|
	236	\| # \| # \| \|
	237	\| # \| # \| \|
	238	\| # \| # \| \|
	239	\| # \| # \| \|
	240	\| # \| # \| \|
be2a608b	241	\| # ↓ # \| \|
1da177e4	242	+----------###############################################----------+-------+
be2a608b	243	\| \| ↑ \| \| \|
1da177e4	244	\| \| \|lower_margin \| \| \|
be2a608b	245	\| \| ↓ \| \| \|
1da177e4	246	+----------+---------------------------------------------+----------+-------+
be2a608b	247	\| \| ↑ \| \| \|
1da177e4	248	\| \| \|vsync_len \| \| \|
be2a608b	249	\| \| ↓ \| \| \|
1da177e4 LT	250	+----------+---------------------------------------------+----------+-------+
	251
	252	The frame buffer device expects all horizontal timings in number of dotclocks
	253	(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
	254
	255
	256	6. Converting XFree86 timing values info frame buffer device timings
	257	--------------------------------------------------------------------
	258
ab42b818 MCC	259	An XFree86 mode line consists of the following fields::
ab42b818 MCC	260
1da177e4 LT	261	"800x600" 50 800 856 976 1040 600 637 643 666
	262	< name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
	263
	264	The frame buffer device uses the following fields:
	265
	266	- pixclock: pixel clock in ps (pico seconds)
	267	- left_margin: time from sync to picture
	268	- right_margin: time from picture to sync
	269	- upper_margin: time from sync to picture
	270	- lower_margin: time from picture to sync
	271	- hsync_len: length of horizontal sync
	272	- vsync_len: length of vertical sync
	273
	274	1) Pixelclock:
ab42b818	275
1da177e4	276	xfree: in MHz
ab42b818	277
1da177e4 LT	278	fb: in picoseconds (ps)
	279
	280	pixclock = 1000000 / DCF
	281
	282	2) horizontal timings:
ab42b818	283
1da177e4	284	left_margin = HFL - SH2
ab42b818	285
1da177e4	286	right_margin = SH1 - HR
ab42b818	287
1da177e4 LT	288	hsync_len = SH2 - SH1
	289
	290	3) vertical timings:
ab42b818	291
1da177e4	292	upper_margin = VFL - SV2
ab42b818	293
1da177e4	294	lower_margin = SV1 - VR
ab42b818	295
1da177e4 LT	296	vsync_len = SV2 - SV1
	297
	298	Good examples for VESA timings can be found in the XFree86 source tree,
	299	under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
	300
	301
	302	7. References
	303	-------------
	304
	305	For more specific information about the frame buffer device and its
	306	applications, please refer to the Linux-fbdev website:
	307
	308	http://linux-fbdev.sourceforge.net/
	309
	310	and to the following documentation:
	311
	312	- The manual pages for fbset: fbset(8), fb.modes(5)
	313	- The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
	314	- The mighty kernel sources:
ab42b818 MCC	315
	316	- linux/drivers/video/
	317	- linux/include/linux/fb.h
	318	- linux/include/video/
1da177e4 LT	319
	320
	321
	322	8. Mailing list
	323	---------------
	324
c69f677c GU	325	There is a frame buffer device related mailing list at kernel.org:
c69f677c GU	326	linux-fbdev@vger.kernel.org.
1da177e4 LT	327
	328	Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
	329	subscription information and archive browsing.
	330
	331
	332	9. Downloading
	333	--------------
	334
	335	All necessary files can be found at
	336
	337	ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
	338
	339	and on its mirrors.
	340
	341	The latest version of fbset can be found at
	342
ab42b818 MCC	343	http://www.linux-fbdev.org/
	344
	345
	346	10. Credits
	347	-----------
1da177e4	348
1da177e4	349	This readme was written by Geert Uytterhoeven, partly based on the original
ab42b818	350	`X-framebuffer.README` by Roman Hodek and Martin Schaller. Section 6 was
1da177e4 LT	351	provided by Frank Neumann.
	352
	353	The frame buffer device abstraction was designed by Martin Schaller.