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