123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136 |
- modedb default video mode support
- Currently all frame buffer device drivers have their own video mode databases,
- which is a mess and a waste of resources. The main idea of modedb is to have
- - one routine to probe for video modes, which can be used by all frame buffer
- devices
- - one generic video mode database with a fair amount of standard videomodes
- (taken from XFree86)
- - the possibility to supply your own mode database for graphics hardware that
- needs non-standard modes, like amifb and Mac frame buffer drivers (which
- use macmodes.c)
- When a frame buffer device receives a video= option it doesn't know, it should
- consider that to be a video mode option. If no frame buffer device is specified
- in a video= option, fbmem considers that to be a global video mode option.
- Valid mode specifiers (mode_option argument):
- <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m]
- <name>[-<bpp>][@<refresh>]
- with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
- Things between square brackets are optional.
- If 'M' is specified in the mode_option argument (after <yres> and before
- <bpp> and <refresh>, if specified) the timings will be calculated using
- VESA(TM) Coordinated Video Timings instead of looking up the mode from a table.
- If 'R' is specified, do a 'reduced blanking' calculation for digital displays.
- If 'i' is specified, calculate for an interlaced mode. And if 'm' is
- specified, add margins to the calculation (1.8% of xres rounded down to 8
- pixels and 1.8% of yres).
- Sample usage: 1024x768M@60m - CVT timing with margins
- ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
- What is the VESA(TM) Coordinated Video Timings (CVT)?
- From the VESA(TM) Website:
- "The purpose of CVT is to provide a method for generating a consistent
- and coordinated set of standard formats, display refresh rates, and
- timing specifications for computer display products, both those
- employing CRTs, and those using other display technologies. The
- intention of CVT is to give both source and display manufacturers a
- common set of tools to enable new timings to be developed in a
- consistent manner that ensures greater compatibility."
- This is the third standard approved by VESA(TM) concerning video timings. The
- first was the Discrete Video Timings (DVT) which is a collection of
- pre-defined modes approved by VESA(TM). The second is the Generalized Timing
- Formula (GTF) which is an algorithm to calculate the timings, given the
- pixelclock, the horizontal sync frequency, or the vertical refresh rate.
- The GTF is limited by the fact that it is designed mainly for CRT displays.
- It artificially increases the pixelclock because of its high blanking
- requirement. This is inappropriate for digital display interface with its high
- data rate which requires that it conserves the pixelclock as much as possible.
- Also, GTF does not take into account the aspect ratio of the display.
- The CVT addresses these limitations. If used with CRT's, the formula used
- is a derivation of GTF with a few modifications. If used with digital
- displays, the "reduced blanking" calculation can be used.
- From the framebuffer subsystem perspective, new formats need not be added
- to the global mode database whenever a new mode is released by display
- manufacturers. Specifying for CVT will work for most, if not all, relatively
- new CRT displays and probably with most flatpanels, if 'reduced blanking'
- calculation is specified. (The CVT compatibility of the display can be
- determined from its EDID. The version 1.3 of the EDID has extra 128-byte
- blocks where additional timing information is placed. As of this time, there
- is no support yet in the layer to parse this additional blocks.)
- CVT also introduced a new naming convention (should be seen from dmesg output):
- <pix>M<a>[-R]
- where: pix = total amount of pixels in MB (xres x yres)
- M = always present
- a = aspect ratio (3 - 4:3; 4 - 5:4; 9 - 15:9, 16:9; A - 16:10)
- -R = reduced blanking
- example: .48M3-R - 800x600 with reduced blanking
- Note: VESA(TM) has restrictions on what is a standard CVT timing:
- - aspect ratio can only be one of the above values
- - acceptable refresh rates are 50, 60, 70 or 85 Hz only
- - if reduced blanking, the refresh rate must be at 60Hz
- If one of the above are not satisfied, the kernel will print a warning but the
- timings will still be calculated.
- ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo *****
- To find a suitable video mode, you just call
- int __init fb_find_mode(struct fb_var_screeninfo *var,
- struct fb_info *info, const char *mode_option,
- const struct fb_videomode *db, unsigned int dbsize,
- const struct fb_videomode *default_mode,
- unsigned int default_bpp)
- with db/dbsize your non-standard video mode database, or NULL to use the
- standard video mode database.
- fb_find_mode() first tries the specified video mode (or any mode that matches,
- e.g. there can be multiple 640x480 modes, each of them is tried). If that
- fails, the default mode is tried. If that fails, it walks over all modes.
- To specify a video mode at bootup, use the following boot options:
- video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
- where <driver> is a name from the table below. Valid default modes can be
- found in linux/drivers/video/modedb.c. Check your driver's documentation.
- There may be more modes.
- Drivers that support modedb boot options
- Boot Name Cards Supported
- amifb - Amiga chipset frame buffer
- aty128fb - ATI Rage128 / Pro frame buffer
- atyfb - ATI Mach64 frame buffer
- pm2fb - Permedia 2/2V frame buffer
- pm3fb - Permedia 3 frame buffer
- sstfb - Voodoo 1/2 (SST1) chipset frame buffer
- tdfxfb - 3D Fx frame buffer
- tridentfb - Trident (Cyber)blade chipset frame buffer
- vt8623fb - VIA 8623 frame buffer
- BTW, only a few drivers use this at the moment. Others are to follow
- (feel free to send patches).
|