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