Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | |
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 | ||
04fee895 | 23 | <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd] |
1da177e4 LT |
24 | <name>[-<bpp>][@<refresh>] |
25 | ||
26 | with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. | |
27 | Things between square brackets are optional. | |
28 | ||
96fe6a21 AD |
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 | ||
04fee895 REB |
39 | DRM drivers also add options to enable or disable outputs: |
40 | ||
41 | 'e' will force the display to be enabled, i.e. it will override the detection | |
42 | if a display is connected. 'D' will force the display to be enabled and use | |
43 | digital output. This is useful for outputs that have both analog and digital | |
44 | signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd' | |
45 | is specified the output is disabled. | |
46 | ||
47 | You can additionally specify which output the options matches to. | |
48 | To force the VGA output to be enabled and drive a specific mode say: | |
49 | video=VGA-1:1280x1024@60me | |
50 | ||
51 | Specifying the option multiple times for different ports is possible, e.g.: | |
52 | video=LVDS-1:d video=HDMI-1:D | |
53 | ||
96fe6a21 AD |
54 | ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** |
55 | ||
56 | What is the VESA(TM) Coordinated Video Timings (CVT)? | |
57 | ||
58 | From the VESA(TM) Website: | |
59 | ||
60 | "The purpose of CVT is to provide a method for generating a consistent | |
61 | and coordinated set of standard formats, display refresh rates, and | |
62 | timing specifications for computer display products, both those | |
63 | employing CRTs, and those using other display technologies. The | |
64 | intention of CVT is to give both source and display manufacturers a | |
65 | common set of tools to enable new timings to be developed in a | |
66 | consistent manner that ensures greater compatibility." | |
67 | ||
68 | This is the third standard approved by VESA(TM) concerning video timings. The | |
69 | first was the Discrete Video Timings (DVT) which is a collection of | |
70 | pre-defined modes approved by VESA(TM). The second is the Generalized Timing | |
71 | Formula (GTF) which is an algorithm to calculate the timings, given the | |
72 | pixelclock, the horizontal sync frequency, or the vertical refresh rate. | |
73 | ||
74 | The GTF is limited by the fact that it is designed mainly for CRT displays. | |
75 | It artificially increases the pixelclock because of its high blanking | |
76 | requirement. This is inappropriate for digital display interface with its high | |
77 | data rate which requires that it conserves the pixelclock as much as possible. | |
78 | Also, GTF does not take into account the aspect ratio of the display. | |
79 | ||
80 | The CVT addresses these limitations. If used with CRT's, the formula used | |
81 | is a derivation of GTF with a few modifications. If used with digital | |
82 | displays, the "reduced blanking" calculation can be used. | |
83 | ||
84 | From the framebuffer subsystem perspective, new formats need not be added | |
85 | to the global mode database whenever a new mode is released by display | |
86 | manufacturers. Specifying for CVT will work for most, if not all, relatively | |
87 | new CRT displays and probably with most flatpanels, if 'reduced blanking' | |
88 | calculation is specified. (The CVT compatibility of the display can be | |
89 | determined from its EDID. The version 1.3 of the EDID has extra 128-byte | |
90 | blocks where additional timing information is placed. As of this time, there | |
91 | is no support yet in the layer to parse this additional blocks.) | |
92 | ||
93 | CVT also introduced a new naming convention (should be seen from dmesg output): | |
94 | ||
95 | <pix>M<a>[-R] | |
96 | ||
97 | where: pix = total amount of pixels in MB (xres x yres) | |
98 | M = always present | |
99 | a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10) | |
100 | -R = reduced blanking | |
101 | ||
102 | example: .48M3-R - 800x600 with reduced blanking | |
103 | ||
104 | Note: VESA(TM) has restrictions on what is a standard CVT timing: | |
105 | ||
106 | - aspect ratio can only be one of the above values | |
107 | - acceptable refresh rates are 50, 60, 70 or 85 Hz only | |
108 | - if reduced blanking, the refresh rate must be at 60Hz | |
109 | ||
110 | If one of the above are not satisfied, the kernel will print a warning but the | |
111 | timings will still be calculated. | |
112 | ||
113 | ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** | |
114 | ||
1da177e4 LT |
115 | To find a suitable video mode, you just call |
116 | ||
117 | int __init fb_find_mode(struct fb_var_screeninfo *var, | |
118 | struct fb_info *info, const char *mode_option, | |
119 | const struct fb_videomode *db, unsigned int dbsize, | |
120 | const struct fb_videomode *default_mode, | |
121 | unsigned int default_bpp) | |
122 | ||
123 | with db/dbsize your non-standard video mode database, or NULL to use the | |
124 | standard video mode database. | |
125 | ||
126 | fb_find_mode() first tries the specified video mode (or any mode that matches, | |
127 | e.g. there can be multiple 640x480 modes, each of them is tried). If that | |
128 | fails, the default mode is tried. If that fails, it walks over all modes. | |
129 | ||
130 | To specify a video mode at bootup, use the following boot options: | |
131 | video=<driver>:<xres>x<yres>[-<bpp>][@refresh] | |
132 | ||
133 | where <driver> is a name from the table below. Valid default modes can be | |
134 | found in linux/drivers/video/modedb.c. Check your driver's documentation. | |
135 | There may be more modes. | |
136 | ||
137 | Drivers that support modedb boot options | |
138 | Boot Name Cards Supported | |
139 | ||
140 | amifb - Amiga chipset frame buffer | |
141 | aty128fb - ATI Rage128 / Pro frame buffer | |
142 | atyfb - ATI Mach64 frame buffer | |
cf6d880c KH |
143 | pm2fb - Permedia 2/2V frame buffer |
144 | pm3fb - Permedia 3 frame buffer | |
145 | sstfb - Voodoo 1/2 (SST1) chipset frame buffer | |
1da177e4 LT |
146 | tdfxfb - 3D Fx frame buffer |
147 | tridentfb - Trident (Cyber)blade chipset frame buffer | |
cf6d880c | 148 | vt8623fb - VIA 8623 frame buffer |
1da177e4 | 149 | |
04fee895 REB |
150 | BTW, only a few fb drivers use this at the moment. Others are to follow |
151 | (feel free to send patches). The DRM drivers also support this. |