1145519Sdarrenr================================= 2145510Sdarrenrmodedb default video mode support 3145510Sdarrenr================================= 4255332Scy 5145510Sdarrenr 6145510SdarrenrCurrently all frame buffer device drivers have their own video mode databases, 7145510Sdarrenrwhich is a mess and a waste of resources. The main idea of modedb is to have 8145510Sdarrenr 9145510Sdarrenr - one routine to probe for video modes, which can be used by all frame buffer 10145510Sdarrenr devices 11145510Sdarrenr - one generic video mode database with a fair amount of standard videomodes 12145510Sdarrenr (taken from XFree86) 13145510Sdarrenr - the possibility to supply your own mode database for graphics hardware that 14145510Sdarrenr needs non-standard modes, like amifb and Mac frame buffer drivers (which 15145510Sdarrenr use macmodes.c) 16145510Sdarrenr 17145510SdarrenrWhen a frame buffer device receives a video= option it doesn't know, it should 18145510Sdarrenrconsider that to be a video mode option. If no frame buffer device is specified 19145510Sdarrenrin a video= option, fbmem considers that to be a global video mode option. 20145510Sdarrenr 21145510SdarrenrValid mode specifiers (mode_option argument):: 22145510Sdarrenr 23145510Sdarrenr <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd] 24145510Sdarrenr <name>[-<bpp>][@<refresh>] 25145510Sdarrenr 26145510Sdarrenrwith <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. 27145510SdarrenrThings between square brackets are optional. 28145510Sdarrenr 29145510SdarrenrValid names are:: 30145510Sdarrenr 31145510Sdarrenr - NSTC: 480i output, with the CCIR System-M TV mode and NTSC color encoding 32145554Sdarrenr - NTSC-J: 480i output, with the CCIR System-M TV mode, the NTSC color 33145510Sdarrenr encoding, and a black level equal to the blanking level. 34145510Sdarrenr - PAL: 576i output, with the CCIR System-B TV mode and PAL color encoding 35255332Scy - PAL-M: 480i output, with the CCIR System-M TV mode and PAL color encoding 36145510Sdarrenr 37145510SdarrenrIf 'M' is specified in the mode_option argument (after <yres> and before 38145510Sdarrenr<bpp> and <refresh>, if specified) the timings will be calculated using 39145510SdarrenrVESA(TM) Coordinated Video Timings instead of looking up the mode from a table. 40145510SdarrenrIf 'R' is specified, do a 'reduced blanking' calculation for digital displays. 41145510SdarrenrIf 'i' is specified, calculate for an interlaced mode. And if 'm' is 42145510Sdarrenrspecified, add margins to the calculation (1.8% of xres rounded down to 8 43145510Sdarrenrpixels and 1.8% of yres). 44145510Sdarrenr 45145510Sdarrenr Sample usage: 1024x768M@60m - CVT timing with margins 46145510Sdarrenr 47145510SdarrenrDRM drivers also add options to enable or disable outputs: 48145510Sdarrenr 49369245Sgit2svn'e' will force the display to be enabled, i.e. it will override the detection 50145510Sdarrenrif a display is connected. 'D' will force the display to be enabled and use 51145510Sdarrenrdigital output. This is useful for outputs that have both analog and digital 52145510Sdarrenrsignals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd' 53145510Sdarrenris specified the output is disabled. 54145510Sdarrenr 55369245Sgit2svnYou can additionally specify which output the options matches to. 56369245Sgit2svnTo force the VGA output to be enabled and drive a specific mode say:: 57369245Sgit2svn 58369245Sgit2svn video=VGA-1:1280x1024@60me 59369245Sgit2svn 60369245Sgit2svnSpecifying the option multiple times for different ports is possible, e.g.:: 61369245Sgit2svn 62369245Sgit2svn video=LVDS-1:d video=HDMI-1:D 63369245Sgit2svn 64369245Sgit2svnOptions can also be passed after the mode, using commas as separator. 65369245Sgit2svn 66369245Sgit2svn Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180 degrees 67369245Sgit2svn 68145510SdarrenrValid options are:: 69145510Sdarrenr 70145510Sdarrenr - margin_top, margin_bottom, margin_left, margin_right (integer): 71145510Sdarrenr Number of pixels in the margins, typically to deal with overscan on TVs 72145510Sdarrenr - reflect_x (boolean): Perform an axial symmetry on the X axis 73145510Sdarrenr - reflect_y (boolean): Perform an axial symmetry on the Y axis 74145510Sdarrenr - rotate (integer): Rotate the initial framebuffer by x 75145510Sdarrenr degrees. Valid values are 0, 90, 180 and 270. 76145510Sdarrenr - tv_mode: Analog TV mode. One of "NTSC", "NTSC-443", "NTSC-J", "PAL", 77145510Sdarrenr "PAL-M", "PAL-N", or "SECAM". 78145510Sdarrenr - panel_orientation, one of "normal", "upside_down", "left_side_up", or 79145510Sdarrenr "right_side_up". For KMS drivers only, this sets the "panel orientation" 80145510Sdarrenr property on the kms connector as hint for kms users. 81145510Sdarrenr 82145510Sdarrenr 83145510Sdarrenr----------------------------------------------------------------------------- 84145510Sdarrenr 85145510SdarrenrWhat is the VESA(TM) Coordinated Video Timings (CVT)? 86145510Sdarrenr===================================================== 87145510Sdarrenr 88145510SdarrenrFrom the VESA(TM) Website: 89145510Sdarrenr 90145510Sdarrenr "The purpose of CVT is to provide a method for generating a consistent 91255332Scy and coordinated set of standard formats, display refresh rates, and 92145510Sdarrenr timing specifications for computer display products, both those 93145510Sdarrenr employing CRTs, and those using other display technologies. The 94145510Sdarrenr intention of CVT is to give both source and display manufacturers a 95145510Sdarrenr common set of tools to enable new timings to be developed in a 96145510Sdarrenr consistent manner that ensures greater compatibility." 97145510Sdarrenr 98145510SdarrenrThis is the third standard approved by VESA(TM) concerning video timings. The 99145510Sdarrenrfirst was the Discrete Video Timings (DVT) which is a collection of 100145510Sdarrenrpre-defined modes approved by VESA(TM). The second is the Generalized Timing 101145510SdarrenrFormula (GTF) which is an algorithm to calculate the timings, given the 102145510Sdarrenrpixelclock, the horizontal sync frequency, or the vertical refresh rate. 103145510Sdarrenr 104145510SdarrenrThe GTF is limited by the fact that it is designed mainly for CRT displays. 105145510SdarrenrIt artificially increases the pixelclock because of its high blanking 106145510Sdarrenrrequirement. This is inappropriate for digital display interface with its high 107145510Sdarrenrdata rate which requires that it conserves the pixelclock as much as possible. 108145510SdarrenrAlso, GTF does not take into account the aspect ratio of the display. 109145510Sdarrenr 110145510SdarrenrThe CVT addresses these limitations. If used with CRT's, the formula used 111145510Sdarrenris a derivation of GTF with a few modifications. If used with digital 112145510Sdarrenrdisplays, the "reduced blanking" calculation can be used. 113145510Sdarrenr 114145510SdarrenrFrom the framebuffer subsystem perspective, new formats need not be added 115145510Sdarrenrto the global mode database whenever a new mode is released by display 116145510Sdarrenrmanufacturers. Specifying for CVT will work for most, if not all, relatively 117145510Sdarrenrnew CRT displays and probably with most flatpanels, if 'reduced blanking' 118145510Sdarrenrcalculation is specified. (The CVT compatibility of the display can be 119145510Sdarrenrdetermined from its EDID. The version 1.3 of the EDID has extra 128-byte 120145510Sdarrenrblocks where additional timing information is placed. As of this time, there 121145510Sdarrenris no support yet in the layer to parse this additional blocks.) 122145510Sdarrenr 123145510SdarrenrCVT also introduced a new naming convention (should be seen from dmesg output):: 124170268Sdarrenr 125170268Sdarrenr <pix>M<a>[-R] 126170268Sdarrenr 127170268Sdarrenr where: pix = total amount of pixels in MB (xres x yres) 128170268Sdarrenr M = always present 129170268Sdarrenr a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10) 130170268Sdarrenr -R = reduced blanking 131170268Sdarrenr 132145510Sdarrenr example: .48M3-R - 800x600 with reduced blanking 133145510Sdarrenr 134145510SdarrenrNote: VESA(TM) has restrictions on what is a standard CVT timing: 135145510Sdarrenr 136145510Sdarrenr - aspect ratio can only be one of the above values 137145510Sdarrenr - acceptable refresh rates are 50, 60, 70 or 85 Hz only 138145510Sdarrenr - if reduced blanking, the refresh rate must be at 60Hz 139145510Sdarrenr 140145510SdarrenrIf one of the above are not satisfied, the kernel will print a warning but the 141145510Sdarrenrtimings will still be calculated. 142145510Sdarrenr 143145510Sdarrenr----------------------------------------------------------------------------- 144145510Sdarrenr 145145510SdarrenrTo find a suitable video mode, you just call:: 146145510Sdarrenr 147145510Sdarrenr int __init fb_find_mode(struct fb_var_screeninfo *var, 148145510Sdarrenr struct fb_info *info, const char *mode_option, 149145510Sdarrenr const struct fb_videomode *db, unsigned int dbsize, 150145510Sdarrenr const struct fb_videomode *default_mode, 151145510Sdarrenr unsigned int default_bpp) 152145510Sdarrenr 153145510Sdarrenrwith db/dbsize your non-standard video mode database, or NULL to use the 154255332Scystandard video mode database. 155145510Sdarrenr 156145510Sdarrenrfb_find_mode() first tries the specified video mode (or any mode that matches, 157145510Sdarrenre.g. there can be multiple 640x480 modes, each of them is tried). If that 158145510Sdarrenrfails, the default mode is tried. If that fails, it walks over all modes. 159145510Sdarrenr 160145510SdarrenrTo specify a video mode at bootup, use the following boot options:: 161145510Sdarrenr 162145510Sdarrenr video=<driver>:<xres>x<yres>[-<bpp>][@refresh] 163145510Sdarrenr 164145510Sdarrenrwhere <driver> is a name from the table below. Valid default modes can be 165145510Sdarrenrfound in drivers/video/fbdev/core/modedb.c. Check your driver's documentation. 166145510SdarrenrThere may be more modes:: 167145510Sdarrenr 168145510Sdarrenr Drivers that support modedb boot options 169145510Sdarrenr Boot Name Cards Supported 170145510Sdarrenr 171145510Sdarrenr amifb - Amiga chipset frame buffer 172145510Sdarrenr aty128fb - ATI Rage128 / Pro frame buffer 173145510Sdarrenr atyfb - ATI Mach64 frame buffer 174145510Sdarrenr pm2fb - Permedia 2/2V frame buffer 175145510Sdarrenr pm3fb - Permedia 3 frame buffer 176145510Sdarrenr sstfb - Voodoo 1/2 (SST1) chipset frame buffer 177145510Sdarrenr tdfxfb - 3D Fx frame buffer 178145510Sdarrenr tridentfb - Trident (Cyber)blade chipset frame buffer 179145510Sdarrenr vt8623fb - VIA 8623 frame buffer 180145510Sdarrenr 181145510SdarrenrBTW, only a few fb drivers use this at the moment. Others are to follow 182145510Sdarrenr(feel free to send patches). The DRM drivers also support this. 183145510Sdarrenr