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