Frame buffer device Driver

Framebuffer
Device is used as a graphics card driver model in the kernel. Many functions and data structures are specific. These specific things provide convenience for our programming. Frame buffer to be developed
Device Driver. You should read the instruction files under source/documentation/FB. The three important files are 00-index,
Framebuffer.txt,internals.txt. Other files are for specific graphics card chips.

File 00-index Translation
Document/documentation/FB index file. If you have any idea about the frame buffer device, mail: Geert uytterhoeven <geert@linux-m68k.org>

00-index file
Framebuffer.txt --- Introduction to frame buffer devices
Internals.txt ---- quick internal browsing of the frame buffer device
Modedb.txt ---- video mode information
Aty128fb.txt ---- Frame Buffer Device for ATI rage128 video card
Clgenfb.txt ----- video card for Cirrus Logic
Matroxfb.txt ---- video card for matrox
Pvr2fb.txt ---- graphics card for powervr 2
Tgafb.txt ---- about TGA (decchip 21030) video card
Vesafb.txt ---- about VESA graphics card

Frame Buffer Device (framebuffer.txt)
Maintenance: Geert uytterhoeven <geert@linux-m68k.org>
Final correction: May 10,200 1
Good02xaut@hotmail.com

0. Introduction
The frame buffer device provides an abstract description of the video card. It also represents the video memory on the video card. The application can access the video card through a defined interface, without knowing any operations at the underlying layer. This device uses a special device node, usually in the/dev directory, such as/dev/FB *.

1. User/dev/FB *
From the user's perspective, frame buffering devices are similar to other devices located under/dev. It is a character device. Generally, the master device number is 29. The sub-device number defines the number of frames buffered.
Generally, use the following method (the device number of the previous digit code)

0 =/dev/fb0 first Frame Buffer
1 =/dev/Fb1 second Frame Buffer
...
31 =/dev/fb31 32nd Frame Buffer

For backward compatibility, you can create symbolic links:

/Dev/fb0current-> fb0
/Dev/fb1current-> Fb1

And so on...

The frame buffer device is also a common memory device that you can read and write its content. For example, screen capture:

CP/dev/fb0 myfile

You can also have multiple display devices at the same time. For example, you have a built-in video card on your motherboard and another independent video card. The corresponding frame buffer device (/dev/fb0 and/dev/Fb1 etc.) can work independently.
Applications such as X Server generally use/dev/fb0 as the default display frame buffer. You can customize a device as the default frame buffer device and set the $ framebuffer environment variable. In sh/Bash:

Export framebuffer =/dev/Fb1

In CSH:

Setenv framebuffer/dev/Fb1

After setting, X server uses the second buffer device.

2. programmer perspective/dev/FB *
As you know, a frame buffer device and memory device are similar to/dev/MEM and have many commonalities. You can read, write, seek, and MMAP (). The difference is that the frame buffer memory is not all memory zones, but the memory dedicated to the video card.
/Dev/FB * allows you to perform IOCTL operations. You can use IOCTL to read or set device parameters. The color ing table is also set through IOCTL. View <Linux/FB. h> to learn how many IOCTL applications and related data structures are available.

Here is a summary:
-You can obtain the same information about the device, such as the device name, the screen structure (plane, pixel,...), and the length and start address of the memory zone.
-You can also obtain information that can change, such as bit depth, color format, and timing. If you change these values, the driver will optimize the values to meet the device features (einval is returned, if your settings are not supported by the device)
-You can also obtain or set some color tables.

All these features make it easy for applications to use devices. X server can use/dev/fb * without knowing how the hardware registers are organized. XF68_FBDev is a bit ing (monochrome) X server. The only thing to do is to set whether to display the application at the corresponding position.

In the new kernel, frame buffering devices can work in modules and allow dynamic loading. This type of driver must call register_framebuffer () to register in the system. More convenient to use modules!

3. Frame Buffer resolution settings
You can use the fbset tool to set the resolution of frame buffering. It can change the display mode of the Video device. The main function is to change the current video mode. For example, when the video is started. * or/etc/init. d/* file. You can change the video mode from monochrome to true color.
Fbset uses the video mode data table stored in the configuration file. You can add the desired display mode to the file.

4. X Server
X server (XF68_FBDev) is the main application of frame buffering devices. After XFree86 3.2, X server is part of XFree86 and has two working modes:
-In the/etc/XF86Config file, if the 'display' section has 'fbdev' Configuration:
Modes "default"
X server will use the environment variable $ FRAMEBUFFER to obtain the current frame buffer device.
You can also set the color Depth, use the Depth keyword, and use Virtual to set the Virtual resolution. This is also the default setting.
-However, you can change the resolution by setting/etc/XF86Config. There is a lot of flexibility, and the only drawback is that you must set the refresh frequency. You can use fbset-x to switch the display mode through fbset or xvidtune.

5. video mode frequency
The CRT display uses three electron guns to strip the phosphor powder to display the color. Electronics
The gun is scanned horizontally from left to right and vertically from top to bottom. By changing the gun voltage, the displayed color can be different. When the electron gun completes a row scan and returns to the beginning of the next row, it is called a horizontal fold.
". After a screen is fully scanned, the electron gun returns to its leftmost foot and is "vertically folded ". The electron gun is disabled on the way back. The speed at which the Electronic Gun Clicks depends on the point clock. If the point clock is
28.37516 MHz. A single point requires 35242 ps.

1/(28.37516E6Hz) = 35.242E-9 s

If the screen resolution is 640x480, the time of a row is:

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

However, it takes time to roll back horizontally. Generally, 272 hitting times are required. Therefore, a row requires a total:

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

We think that the horizontal scan frequency is 31 KHz:

1/(32.141E-6 s) = 31.113E3Hz

A screen contains 480 rows, plus a vertical return time of 49, the time required for a screen:

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

We think that the vertical scan frequency is 59Hz:

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

This also means that the screen data is refreshed 59 times per second. To achieve stable image display, the vertical scan frequency of VESA is no less than 72Hz. But it also varies from person to person. Some people do not feel any problems at 50Hz, and some do not need to be at least 80Hz.
By
When the monitor does not know when a new line starts scanning, the video card provides a horizontal synchronous signal for each line of scanning. Similarly, it provides a vertical synchronization signal for each frame display. The position of the image on the screen depends on
The occurrence time of the step signal. A summary of all time sequences is provided. The horizontal return time is the left blank + right blank + Horizontal synchronization length. The vertical fold-back time is the upper blank + lower blank + vertical with the same step size.

+ ---------- + --------------------------------------------- + ---------- + ------- +
| ^ |
| Upper_margin |
|? |
+ ----------###################################### ######### ---------- + ------- +
| # ^ # |
| #|#| |
| #|#| |
| #|#| |
| Left # | # right | hsync |
| Margin # | xres # margin | len |
| <-------- >#< --------------- + --------------------------- >#< -------- >|< -----> |
| #|#| |
| #|#| |
| #|#| |
| # | Yres # |
| #|#| |
| #|#| |
| #|#| |
| #|#| |
| #|#| |
| #|#| |
| #|#| |
| #|#| |
| #? # |
+ ----------###################################### ######### ---------- + ------- +
| ^ |
| Lower_margin |
|? |
+ ---------- + --------------------------------------------- + ---------- + ------- +
| ^ |
| Vsync_len |
|? |
+ ---------- + --------------------------------------------- + ---------- + ------- +

6. Change the XFree86 sequence to the frame buffer device sequence.
Typical display mode:

"800x600" 50 800 856 976 1040 600 637 643
<Name> dcf hr SH1 SH2 hfl vr SV1 SV2 VFL

The frame buffer device uses the following parameters:

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

A better VESA example can be found in XFree86 source code, "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt ".

 

Internal data structure of Frame Buffer equipment (internals.txt)
Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
Good02xaut@hotmail.com

The struct used by the xxx frame buffer device.
The following data structure is used on frame buffering devices and is defined in <linux/fb. h>.

1. Outside the kernel (user space)

• Struct fb_fix_screeninfo
  The device-independent constant value data in the frame buffer device. It can be obtained through fbioget_fscreeninfo of IOCTL.
• Struct fb_var_screeninfo
  Variable data irrelevant to the device in the frame buffer device and the specific display mode. It can be obtained through fbioget_vscreeninfo of iotcl and set through fbioput_vscreeninfo of IOCTL. You can also use fbiopan_display.
• Struct fb_cmap
  The color table information unrelated to the device. You can read or set it through FBIOGETCMAP and FBIOPUTCMAP of ioctl.

2. Inside the kernel

• Struct fb_info
  General information, API, and underlying information of the frame buffer device (motherboard address ...).
• Struct 'par'
  Device information that uniquely specifies the display mode of the device.
• Struct display
  The interface between the frame buffer device and the console driver.

--------------------------------------------------------------------------------

* ** Common Frame Buffer APIs ***

Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)

-------------------------------------------------

Each pixel is black or white.
Pseudo color (fb_visual_pseudo docolor and fb_visual_static_pseudo docolor)
---------------------------------------------------------------------

Index Color Display
True color (fb_visual_truecolor)
--------------------------------

True Color Display, divided into three basic colors: Red, green, and blue
Direct color (fb_visual_directcolor)
------------------------------------

Each pixel color is also composed of red, green, and blue. However, each color value is an index and needs to be queried.
Grayscale displays
------------------

Gray-scale display, with the same red, green, and Blue values