The Frame Buffer Device--帧缓冲设备

本文详细介绍了Linux系统的帧缓冲设备原理及应用,包括设备文件、硬件抽象层、编程接口、分辨率设置工具fbset以及X服务器配置等内容。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  1                         The Frame Buffer Device

  2                         -----------------------

  3 

  4 Maintained by Geert Uytterhoeven <geert@linux-m68k.org>
  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

 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 create the following symbolic

 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' memory devices, this means, you can

 45 read and write their contents. You can, for example, make a screen snapshot by

 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

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

 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 

 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 

116 Frame buffer resolutions are maintained using the utility `fbset'. It can

117 change the video mode properties of a frame buffer device. Its main usage is

118 to change the current video mode, e.g. during boot up in one of your /etc/rc.*

119 or /etc/init.d/* files.

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 

132   - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config

133     file contains a

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

149     specify the timings in a different format (but `fbset -x' may help).

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

175 of cycles per second), each pixel is 35242 ps (picoseconds) long:

176 

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

178 

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

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

184 also takes time (e.g. 272 `pixels'), so a full scanline takes

185 

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

187 

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

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

193 retrace too (e.g. 49 `pixels'). So a full screen will take

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

215 vsync length.

216 

217   +----------+---------------------------------------------+----------+-------+

218   |          |                ^                            |          |       |

219   |          |                |upper_margin                |          |       |

220   |          |                ¥                            |          |       |

221   +----------###############################################----------+-------+

222   |          #                ^                            #          |       |

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

241   |          #                ¥                            #          |       |

242   +----------###############################################----------+-------+
243   |          |                ^                            |          |       |
244   |          |                |lower_margin                |          |       |

245   |          |                ¥                            |          |       |
246   +----------+---------------------------------------------+----------+-------+

247   |          |                ^                            |          |       |
248   |          |                |vsync_len                   |          |       |
249   |          |                ¥                            |          |       |
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 
259 An XFree86 mode line consists of the following fields:
260  "800x600"     50      800  856  976 1040    600  637  643  666
261  < name >     DCF       HR  SH1  SH2  HFL     VR  SV1  SV2  VFL
262 
263 The frame buffer device uses the following fields:
264 
265   - pixclock: pixel clock in ps (pico seconds)
266   - left_margin: time from sync to picture
267   - right_margin: time from picture to sync
268   - upper_margin: time from sync to picture
269   - lower_margin: time from picture to sync
270   - hsync_len: length of horizontal sync
271   - vsync_len: length of vertical sync
272 
273 1) Pixelclock:
274    xfree: in MHz
275    fb: in picoseconds (ps)
276 
277    pixclock = 1000000 / DCF
278 
279 2) horizontal timings:
280    left_margin = HFL - SH2
281    right_margin = SH1 - HR
282    hsync_len = SH2 - SH1
 
283 
284 3) vertical timings:
285    upper_margin = VFL - SV2
286    lower_margin = SV1 - VR
287    vsync_len = SV2 - SV1
288 
289 Good examples for VESA timings can be found in the XFree86 source tree,
290 under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
291 
292 
293 7. References
294 -------------
295 
296 For more specific information about the frame buffer device and its
297 applications, please refer to the Linux-fbdev website:
298 
299     http://linux-fbdev.sourceforge.net/
300 
301 and to the following documentation:
302 
303   - The manual pages for fbset: fbset(8), fb.modes(5)
304   - The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
305   - The mighty kernel sources:
 
306       o linux/drivers/video/
307       o linux/include/linux/fb.h
308       o linux/include/video/
309 
310 
311 
 
312 8. Mailing list
313 ---------------
314 
315 There are several frame buffer device related mailing lists at SourceForge:
316   - linux-fbdev-announce@lists.sourceforge.net, for announcements,
317   - linux-fbdev-user@lists.sourceforge.net, for generic user support,
318   - linux-fbdev-devel@lists.sourceforge.net, for project developers.
319 
320 Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
321 subscription information and archive browsing.
322 
323 
324 9. Downloading
325 --------------
326 
327 All necessary files can be found at
328 
329     ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
330 
331 and on its mirrors.
332 
333 The latest version of fbset can be found at
334 
335     http://home.tvd.be/cr26864/Linux/fbdev/
336 
337   
338 10. Credits                                                       
339 ----------                                                       
340                 
341 This readme was written by Geert Uytterhoeven, partly based on the original
342 `X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
343 provided by Frank Neumann.
344 
345 The frame buffer device abstraction was designed by Martin Schaller.

 

附录(added by wave):

1.    在csdn上找到一篇此文的翻译版本,这就省去了我翻译的时间了。链接如下:

http://blog.youkuaiyun.com/ganxingming/archive/2006/06/05/774869.aspx

2.   帧缓冲驱动网站:

           http://linux-fbdev.sourceforge.net

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值