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