1 =======================
2 The Frame Buffer Device
3 =======================
4
5 Last revised: May 10, 2001
6
7
8 0. Introduction
9 ---------------
10
11 The frame buffer device provides an abstractio
12 represents the frame buffer of some video hard
13 software to access the graphics hardware throu
14 the software doesn't need to know anything abo
15 register) stuff.
16
17 The device is accessed through special device
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 buffe
25 other device in /dev. It's a character device
26 specifies the frame buffer number.
27
28 By convention, the following device nodes are
29 minor numbers)::
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 c
37 links::
38
39 /dev/fb0current -> fb0
40 /dev/fb1current -> fb1
41
42 and so on...
43
44 The frame buffer devices are also `normal` mem
45 read and write their contents. You can, for ex
46
47 cp /dev/fb0 myfile
48
49 There also can be more than one frame buffer a
50 graphics card in addition to the built-in hard
51 buffer devices (/dev/fb0 and /dev/fb1 etc.) wo
52
53 Application software that uses the frame buffe
54 use /dev/fb0 by default (older software uses /
55 an alternative frame buffer device by setting
56 $FRAMEBUFFER to the path name of a frame buffe
57 users)::
58
59 export FRAMEBUFFER=/dev/fb1
60
61 or (for csh users)::
62
63 setenv FRAMEBUFFER /dev/fb1
64
65 After this the X server will use the second fr
66
67
68 2. Programmer's View of /dev/fb*
69 --------------------------------
70
71 As you already know, a frame buffer device is
72 it has the same features. You can read it, wri
73 it and mmap() it (the main usage). The differe
74 appears in the special file is not the whole m
75 some video hardware.
76
77 /dev/fb* also allows several ioctls on it, by
78 the hardware can be queried and set. The color
79 too. Look into <linux/fb.h> for more informati
80 which data structures they work. Here's just a
81
82 - You can request unchangeable information a
83 organization of the screen memory (planes,
84 and length of the screen memory.
85
86 - You can request and change variable inform
87 visible and virtual geometry, depth, color
88 If you try to change that information, the
89 values to meet the hardware's capabilities
90 possible).
91
92 - You can get and set parts of the color map
93 bits per color part (red, green, blue, tra
94 existing hardware. The driver does all the
95 it to the hardware (round it down to less
96 transparency).
97
98 All this hardware abstraction makes the implem
99 easier and more portable. E.g. the X server wo
100 thus doesn't need to know, for example, how th
101 hardware are organized. XF68_FBDev is a genera
102 unaccelerated video hardware. The only thing t
103 application programs is the screen organizatio
104 etc.), because it works on the frame buffer im
105
106 For the future it is planned that frame buffer
107 the like can be implemented as kernel modules
108 a driver just has to call register_framebuffer
109 Writing and distributing such drivers independ
110 much trouble...
111
112
113 3. Frame Buffer Resolution Maintenance
114 --------------------------------------
115
116 Frame buffer resolutions are maintained using
117 change the video mode properties of a frame bu
118 to change the current video mode, e.g. during
119 or `/etc/init.d/*` files.
120
121 Fbset uses a video mode database stored in a c
122 easily add your own modes and refer to them wi
123
124
125 4. The X Server
126 ---------------
127
128 The X server (XF68_FBDev) is the most notable
129 buffer device. Starting with XFree86 release 3
130 XFree86 and has 2 modes:
131
132 - If the `Display` subsection for the `fbdev
133 file contains a::
134
135 Modes "default"
136
137 line, the X server will use the scheme dis
138 up in the resolution determined by /dev/fb
139 still have to specify the color depth (usi
140 resolution (using the Virtual keyword) tho
141 configuration file supplied with XFree86.
142 configuration, but it has some limitations
143
144 - Therefore it's also possible to specify re
145 file. This allows for on-the-fly resolutio
146 same virtual desktop size. The frame buffe
147 /dev/fb0current (or $FRAMEBUFFER), but the
148 defined by /etc/XF86Config now. The disadv
149 specify the timings in a different format
150
151 To tune a video mode, you can use fbset or xvi
152 work 100% with XF68_FBDev: the reported clock
153
154
155 5. Video Mode Timings
156 ---------------------
157
158 A monitor draws an image on the screen by usin
159 beams for color models, 1 electron beam for mo
160 the screen is covered by a pattern of colored
161 is hit by an electron, it emits a photon and t
162
163 The electron beam draws horizontal lines (scan
164 from the top to the bottom of the screen. By m
165 electron beam, pixels with various colors and
166
167 After each scanline the electron beam has to m
168 screen and to the next line: this is called th
169 whole screen (frame) was painted, the beam mov
170 this is called the vertical retrace. During bo
171 retrace, the electron beam is turned off (blan
172
173 The speed at which the electron beam paints th
174 dotclock in the graphics board. For a dotclock
175 of cycles per second), each pixel is 35242 ps
176
177 1/(28.37516E6 Hz) = 35.242E-9 s
178
179 If the screen resolution is 640x480, it will t
180
181 640*35.242E-9 s = 22.555E-6 s
182
183 to paint the 640 (xres) pixels on one scanline
184 also takes time (e.g. 272 `pixels`), so a full
185
186 (640+272)*35.242E-9 s = 32.141E-6 s
187
188 We'll say that the horizontal scanrate is abou
189
190 1/(32.141E-6 s) = 31.113E3 Hz
191
192 A full screen counts 480 (yres) lines, but we
193 retrace too (e.g. 49 `lines`). So a full scree
194
195 (480+49)*32.141E-6 s = 17.002E-3 s
196
197 The vertical scanrate is about 59 Hz::
198
199 1/(17.002E-3 s) = 58.815 Hz
200
201 This means the screen data is refreshed about
202 stable picture without visible flicker, VESA r
203 at least 72 Hz. But the perceived flicker is v
204 can use 50 Hz without any trouble, while I'll
205
206 Since the monitor doesn't know when a new scan
207 will supply a synchronization pulse (horizonta
208 scanline. Similarly it supplies a synchroniza
209 vsync) for each new frame. The position of the
210 influenced by the moments at which the synchro
211
212 The following picture summarizes all timings.
213 the sum of the left margin, the right margin a
214 vertical retrace time is the sum of the upper
215 vsync length::
216
217 +----------+--------------------------------
218 | | ↑
219 | | |upper_margin
220 | | ↓
221 +----------#################################
222 | # ↑
223 | # |
224 | # |
225 | # |
226 | left # |
227 | margin # | xres
228 |<-------->#<---------------+---------------
229 | # |
230 | # |
231 | # |
232 | # |yres
233 | # |
234 | # |
235 | # |
236 | # |
237 | # |
238 | # |
239 | # |
240 | # |
241 | # ↓
242 +----------#################################
243 | | ↑
244 | | |lower_margin
245 | | ↓
246 +----------+--------------------------------
247 | | ↑
248 | | |vsync_len
249 | | ↓
250 +----------+--------------------------------
251
252 The frame buffer device expects all horizontal
253 (in picoseconds, 1E-12 s), and vertical timing
254
255
256 6. Converting XFree86 timing values info frame
257 ----------------------------------------------
258
259 An XFree86 mode line consists of the following
260
261 "800x600" 50 800 856 976 1040 6
262 < name > DCF HR SH1 SH2 HFL
263
264 The frame buffer device uses the following fie
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:
275
276 xfree: in MHz
277
278 fb: in picoseconds (ps)
279
280 pixclock = 1000000 / DCF
281
282 2) horizontal timings:
283
284 left_margin = HFL - SH2
285
286 right_margin = SH1 - HR
287
288 hsync_len = SH2 - SH1
289
290 3) vertical timings:
291
292 upper_margin = VFL - SV2
293
294 lower_margin = SV1 - VR
295
296 vsync_len = SV2 - SV1
297
298 Good examples for VESA timings can be found in
299 under "xc/programs/Xserver/hw/xfree86/doc/mode
300
301
302 7. References
303 -------------
304
305 For more specific information about the frame
306 applications, please refer to the Linux-fbdev
307
308 http://linux-fbdev.sourceforge.net/
309
310 and to the following documentation:
311
312 - The manual pages for fbset: fbset(8), fb.m
313 - The manual pages for XFree86: XF68_FBDev(1
314 - The mighty kernel sources:
315
316 - linux/drivers/video/
317 - linux/include/linux/fb.h
318 - linux/include/video/
319
320
321
322 8. Mailing list
323 ---------------
324
325 There is a frame buffer device related mailing
326 linux-fbdev@vger.kernel.org.
327
328 Point your web browser to http://sourceforge.n
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/
338
339 and on its mirrors.
340
341 The latest version of fbset can be found at
342
343 http://www.linux-fbdev.org/
344
345
346 10. Credits
347 -----------
348
349 This readme was written by Geert Uytterhoeven,
350 `X-framebuffer.README` by Roman Hodek and Mart
351 provided by Frank Neumann.
352
353 The frame buffer device abstraction was design
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.