1 |
3 |
xianfeng |
|
2 |
|
|
|
3 |
|
|
modedb default video mode support
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
Currently all frame buffer device drivers have their own video mode databases,
|
7 |
|
|
which is a mess and a waste of resources. The main idea of modedb is to have
|
8 |
|
|
|
9 |
|
|
- one routine to probe for video modes, which can be used by all frame buffer
|
10 |
|
|
devices
|
11 |
|
|
- one generic video mode database with a fair amount of standard videomodes
|
12 |
|
|
(taken from XFree86)
|
13 |
|
|
- the possibility to supply your own mode database for graphics hardware that
|
14 |
|
|
needs non-standard modes, like amifb and Mac frame buffer drivers (which
|
15 |
|
|
use macmodes.c)
|
16 |
|
|
|
17 |
|
|
When a frame buffer device receives a video= option it doesn't know, it should
|
18 |
|
|
consider that to be a video mode option. If no frame buffer device is specified
|
19 |
|
|
in a video= option, fbmem considers that to be a global video mode option.
|
20 |
|
|
|
21 |
|
|
Valid mode specifiers (mode_option argument):
|
22 |
|
|
|
23 |
|
|
x[M][R][-][@][i][m]
|
24 |
|
|
[-][@]
|
25 |
|
|
|
26 |
|
|
with , , and decimal numbers and a string.
|
27 |
|
|
Things between square brackets are optional.
|
28 |
|
|
|
29 |
|
|
If 'M' is specified in the mode_option argument (after and before
|
30 |
|
|
and , if specified) the timings will be calculated using
|
31 |
|
|
VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
|
32 |
|
|
If 'R' is specified, do a 'reduced blanking' calculation for digital displays.
|
33 |
|
|
If 'i' is specified, calculate for an interlaced mode. And if 'm' is
|
34 |
|
|
specified, add margins to the calculation (1.8% of xres rounded down to 8
|
35 |
|
|
pixels and 1.8% of yres).
|
36 |
|
|
|
37 |
|
|
Sample usage: 1024x768M@60m - CVT timing with margins
|
38 |
|
|
|
39 |
|
|
***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
|
40 |
|
|
|
41 |
|
|
What is the VESA(TM) Coordinated Video Timings (CVT)?
|
42 |
|
|
|
43 |
|
|
From the VESA(TM) Website:
|
44 |
|
|
|
45 |
|
|
"The purpose of CVT is to provide a method for generating a consistent
|
46 |
|
|
and coordinated set of standard formats, display refresh rates, and
|
47 |
|
|
timing specifications for computer display products, both those
|
48 |
|
|
employing CRTs, and those using other display technologies. The
|
49 |
|
|
intention of CVT is to give both source and display manufacturers a
|
50 |
|
|
common set of tools to enable new timings to be developed in a
|
51 |
|
|
consistent manner that ensures greater compatibility."
|
52 |
|
|
|
53 |
|
|
This is the third standard approved by VESA(TM) concerning video timings. The
|
54 |
|
|
first was the Discrete Video Timings (DVT) which is a collection of
|
55 |
|
|
pre-defined modes approved by VESA(TM). The second is the Generalized Timing
|
56 |
|
|
Formula (GTF) which is an algorithm to calculate the timings, given the
|
57 |
|
|
pixelclock, the horizontal sync frequency, or the vertical refresh rate.
|
58 |
|
|
|
59 |
|
|
The GTF is limited by the fact that it is designed mainly for CRT displays.
|
60 |
|
|
It artificially increases the pixelclock because of its high blanking
|
61 |
|
|
requirement. This is inappropriate for digital display interface with its high
|
62 |
|
|
data rate which requires that it conserves the pixelclock as much as possible.
|
63 |
|
|
Also, GTF does not take into account the aspect ratio of the display.
|
64 |
|
|
|
65 |
|
|
The CVT addresses these limitations. If used with CRT's, the formula used
|
66 |
|
|
is a derivation of GTF with a few modifications. If used with digital
|
67 |
|
|
displays, the "reduced blanking" calculation can be used.
|
68 |
|
|
|
69 |
|
|
From the framebuffer subsystem perspective, new formats need not be added
|
70 |
|
|
to the global mode database whenever a new mode is released by display
|
71 |
|
|
manufacturers. Specifying for CVT will work for most, if not all, relatively
|
72 |
|
|
new CRT displays and probably with most flatpanels, if 'reduced blanking'
|
73 |
|
|
calculation is specified. (The CVT compatibility of the display can be
|
74 |
|
|
determined from its EDID. The version 1.3 of the EDID has extra 128-byte
|
75 |
|
|
blocks where additional timing information is placed. As of this time, there
|
76 |
|
|
is no support yet in the layer to parse this additional blocks.)
|
77 |
|
|
|
78 |
|
|
CVT also introduced a new naming convention (should be seen from dmesg output):
|
79 |
|
|
|
80 |
|
|
M[-R]
|
81 |
|
|
|
82 |
|
|
where: pix = total amount of pixels in MB (xres x yres)
|
83 |
|
|
M = always present
|
84 |
|
|
a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10)
|
85 |
|
|
-R = reduced blanking
|
86 |
|
|
|
87 |
|
|
example: .48M3-R - 800x600 with reduced blanking
|
88 |
|
|
|
89 |
|
|
Note: VESA(TM) has restrictions on what is a standard CVT timing:
|
90 |
|
|
|
91 |
|
|
- aspect ratio can only be one of the above values
|
92 |
|
|
- acceptable refresh rates are 50, 60, 70 or 85 Hz only
|
93 |
|
|
- if reduced blanking, the refresh rate must be at 60Hz
|
94 |
|
|
|
95 |
|
|
If one of the above are not satisfied, the kernel will print a warning but the
|
96 |
|
|
timings will still be calculated.
|
97 |
|
|
|
98 |
|
|
***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
|
99 |
|
|
|
100 |
|
|
To find a suitable video mode, you just call
|
101 |
|
|
|
102 |
|
|
int __init fb_find_mode(struct fb_var_screeninfo *var,
|
103 |
|
|
struct fb_info *info, const char *mode_option,
|
104 |
|
|
const struct fb_videomode *db, unsigned int dbsize,
|
105 |
|
|
const struct fb_videomode *default_mode,
|
106 |
|
|
unsigned int default_bpp)
|
107 |
|
|
|
108 |
|
|
with db/dbsize your non-standard video mode database, or NULL to use the
|
109 |
|
|
standard video mode database.
|
110 |
|
|
|
111 |
|
|
fb_find_mode() first tries the specified video mode (or any mode that matches,
|
112 |
|
|
e.g. there can be multiple 640x480 modes, each of them is tried). If that
|
113 |
|
|
fails, the default mode is tried. If that fails, it walks over all modes.
|
114 |
|
|
|
115 |
|
|
To specify a video mode at bootup, use the following boot options:
|
116 |
|
|
video=:x[-][@refresh]
|
117 |
|
|
|
118 |
|
|
where is a name from the table below. Valid default modes can be
|
119 |
|
|
found in linux/drivers/video/modedb.c. Check your driver's documentation.
|
120 |
|
|
There may be more modes.
|
121 |
|
|
|
122 |
|
|
Drivers that support modedb boot options
|
123 |
|
|
Boot Name Cards Supported
|
124 |
|
|
|
125 |
|
|
amifb - Amiga chipset frame buffer
|
126 |
|
|
aty128fb - ATI Rage128 / Pro frame buffer
|
127 |
|
|
atyfb - ATI Mach64 frame buffer
|
128 |
|
|
tdfxfb - 3D Fx frame buffer
|
129 |
|
|
tridentfb - Trident (Cyber)blade chipset frame buffer
|
130 |
|
|
|
131 |
|
|
BTW, only a few drivers use this at the moment. Others are to follow
|
132 |
|
|
(feel free to send patches).
|