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