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