diff options
author | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@ppc970.osdl.org> | 2005-04-16 15:20:36 -0700 |
commit | 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 (patch) | |
tree | 0bba044c4ce775e45a88a51686b5d9f90697ea9d /Documentation/fb/modedb.txt |
Linux-2.6.12-rc2v2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
Diffstat (limited to 'Documentation/fb/modedb.txt')
-rw-r--r-- | Documentation/fb/modedb.txt | 61 |
1 files changed, 61 insertions, 0 deletions
diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt new file mode 100644 index 000000000000..e04458b319d5 --- /dev/null +++ b/Documentation/fb/modedb.txt @@ -0,0 +1,61 @@ + + + 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>[-<bpp>][@<refresh>] + <name>[-<bpp>][@<refresh>] + +with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. +Things between square brackets are optional. + +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 + tdfxfb - 3D Fx frame buffer + tridentfb - Trident (Cyber)blade chipset frame buffer + +BTW, only a few drivers use this at the moment. Others are to follow +(feel free to send patches). |