Commit | Line | Data |
---|---|---|
ab42b818 MCC |
1 | ================================= |
2 | modedb default video mode support | |
3 | ================================= | |
1da177e4 LT |
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 | ||
ab42b818 | 21 | Valid mode specifiers (mode_option argument):: |
1da177e4 | 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. | |
ab42b818 MCC |
48 | To force the VGA output to be enabled and drive a specific mode say:: |
49 | ||
04fee895 REB |
50 | video=VGA-1:1280x1024@60me |
51 | ||
ab42b818 MCC |
52 | Specifying the option multiple times for different ports is possible, e.g.:: |
53 | ||
04fee895 REB |
54 | video=LVDS-1:d video=HDMI-1:D |
55 | ||
1bf4e092 MR |
56 | Options can also be passed after the mode, using commas as separator. |
57 | ||
58 | Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180 degrees | |
59 | ||
be8454af | 60 | Valid options are:: |
1bf4e092 | 61 | |
3d46a300 MR |
62 | - margin_top, margin_bottom, margin_left, margin_right (integer): |
63 | Number of pixels in the margins, typically to deal with overscan on TVs | |
1bf4e092 MR |
64 | - reflect_x (boolean): Perform an axial symmetry on the X axis |
65 | - reflect_y (boolean): Perform an axial symmetry on the Y axis | |
66 | - rotate (integer): Rotate the initial framebuffer by x | |
67 | degrees. Valid values are 0, 90, 180 and 270. | |
4e7a4a6f HG |
68 | - panel_orientation, one of "normal", "upside_down", "left_side_up", or |
69 | "right_side_up". For KMS drivers only, this sets the "panel orientation" | |
70 | property on the kms connector as hint for kms users. | |
1bf4e092 MR |
71 | |
72 | ||
ab42b818 | 73 | ----------------------------------------------------------------------------- |
96fe6a21 AD |
74 | |
75 | What is the VESA(TM) Coordinated Video Timings (CVT)? | |
ab42b818 | 76 | ===================================================== |
96fe6a21 AD |
77 | |
78 | From the VESA(TM) Website: | |
79 | ||
80 | "The purpose of CVT is to provide a method for generating a consistent | |
81 | and coordinated set of standard formats, display refresh rates, and | |
82 | timing specifications for computer display products, both those | |
83 | employing CRTs, and those using other display technologies. The | |
84 | intention of CVT is to give both source and display manufacturers a | |
85 | common set of tools to enable new timings to be developed in a | |
86 | consistent manner that ensures greater compatibility." | |
87 | ||
88 | This is the third standard approved by VESA(TM) concerning video timings. The | |
89 | first was the Discrete Video Timings (DVT) which is a collection of | |
90 | pre-defined modes approved by VESA(TM). The second is the Generalized Timing | |
91 | Formula (GTF) which is an algorithm to calculate the timings, given the | |
92 | pixelclock, the horizontal sync frequency, or the vertical refresh rate. | |
93 | ||
94 | The GTF is limited by the fact that it is designed mainly for CRT displays. | |
95 | It artificially increases the pixelclock because of its high blanking | |
96 | requirement. This is inappropriate for digital display interface with its high | |
97 | data rate which requires that it conserves the pixelclock as much as possible. | |
98 | Also, GTF does not take into account the aspect ratio of the display. | |
99 | ||
100 | The CVT addresses these limitations. If used with CRT's, the formula used | |
101 | is a derivation of GTF with a few modifications. If used with digital | |
102 | displays, the "reduced blanking" calculation can be used. | |
103 | ||
104 | From the framebuffer subsystem perspective, new formats need not be added | |
105 | to the global mode database whenever a new mode is released by display | |
106 | manufacturers. Specifying for CVT will work for most, if not all, relatively | |
107 | new CRT displays and probably with most flatpanels, if 'reduced blanking' | |
108 | calculation is specified. (The CVT compatibility of the display can be | |
109 | determined from its EDID. The version 1.3 of the EDID has extra 128-byte | |
110 | blocks where additional timing information is placed. As of this time, there | |
111 | is no support yet in the layer to parse this additional blocks.) | |
112 | ||
ab42b818 | 113 | CVT also introduced a new naming convention (should be seen from dmesg output):: |
96fe6a21 AD |
114 | |
115 | <pix>M<a>[-R] | |
116 | ||
117 | where: pix = total amount of pixels in MB (xres x yres) | |
ab42b818 MCC |
118 | M = always present |
119 | a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10) | |
120 | -R = reduced blanking | |
96fe6a21 AD |
121 | |
122 | example: .48M3-R - 800x600 with reduced blanking | |
123 | ||
124 | Note: VESA(TM) has restrictions on what is a standard CVT timing: | |
125 | ||
126 | - aspect ratio can only be one of the above values | |
127 | - acceptable refresh rates are 50, 60, 70 or 85 Hz only | |
128 | - if reduced blanking, the refresh rate must be at 60Hz | |
129 | ||
130 | If one of the above are not satisfied, the kernel will print a warning but the | |
131 | timings will still be calculated. | |
132 | ||
ab42b818 | 133 | ----------------------------------------------------------------------------- |
96fe6a21 | 134 | |
ab42b818 | 135 | To find a suitable video mode, you just call:: |
1da177e4 | 136 | |
ab42b818 MCC |
137 | int __init fb_find_mode(struct fb_var_screeninfo *var, |
138 | struct fb_info *info, const char *mode_option, | |
139 | const struct fb_videomode *db, unsigned int dbsize, | |
140 | const struct fb_videomode *default_mode, | |
141 | unsigned int default_bpp) | |
1da177e4 LT |
142 | |
143 | with db/dbsize your non-standard video mode database, or NULL to use the | |
144 | standard video mode database. | |
145 | ||
146 | fb_find_mode() first tries the specified video mode (or any mode that matches, | |
147 | e.g. there can be multiple 640x480 modes, each of them is tried). If that | |
148 | fails, the default mode is tried. If that fails, it walks over all modes. | |
149 | ||
ab42b818 MCC |
150 | To specify a video mode at bootup, use the following boot options:: |
151 | ||
1da177e4 LT |
152 | video=<driver>:<xres>x<yres>[-<bpp>][@refresh] |
153 | ||
154 | where <driver> is a name from the table below. Valid default modes can be | |
155 | found in linux/drivers/video/modedb.c. Check your driver's documentation. | |
ab42b818 | 156 | There may be more modes:: |
1da177e4 LT |
157 | |
158 | Drivers that support modedb boot options | |
159 | Boot Name Cards Supported | |
160 | ||
161 | amifb - Amiga chipset frame buffer | |
162 | aty128fb - ATI Rage128 / Pro frame buffer | |
163 | atyfb - ATI Mach64 frame buffer | |
cf6d880c KH |
164 | pm2fb - Permedia 2/2V frame buffer |
165 | pm3fb - Permedia 3 frame buffer | |
166 | sstfb - Voodoo 1/2 (SST1) chipset frame buffer | |
1da177e4 LT |
167 | tdfxfb - 3D Fx frame buffer |
168 | tridentfb - Trident (Cyber)blade chipset frame buffer | |
cf6d880c | 169 | vt8623fb - VIA 8623 frame buffer |
1da177e4 | 170 | |
04fee895 REB |
171 | BTW, only a few fb drivers use this at the moment. Others are to follow |
172 | (feel free to send patches). The DRM drivers also support this. |