diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/fb/modedb.txt | 73 |
1 files changed, 72 insertions, 1 deletions
diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt index e04458b319d5..4fcdb4cf4cca 100644 --- a/Documentation/fb/modedb.txt +++ b/Documentation/fb/modedb.txt | |||
@@ -20,12 +20,83 @@ in a video= option, fbmem considers that to be a global video mode option. | |||
20 | 20 | ||
21 | Valid mode specifiers (mode_option argument): | 21 | Valid mode specifiers (mode_option argument): |
22 | 22 | ||
23 | <xres>x<yres>[-<bpp>][@<refresh>] | 23 | <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m] |
24 | <name>[-<bpp>][@<refresh>] | 24 | <name>[-<bpp>][@<refresh>] |
25 | 25 | ||
26 | with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. | 26 | with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. |
27 | Things between square brackets are optional. | 27 | Things between square brackets are optional. |
28 | 28 | ||
29 | If 'M' is specified in the mode_option argument (after <yres> and before | ||
30 | <bpp> and <refresh>, 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 | <pix>M<a>[-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 | |||
29 | To find a suitable video mode, you just call | 100 | To find a suitable video mode, you just call |
30 | 101 | ||
31 | int __init fb_find_mode(struct fb_var_screeninfo *var, | 102 | int __init fb_find_mode(struct fb_var_screeninfo *var, |