OpenCloudOS-Kernel/Documentation/fb/modedb.rst

183 lines
8.0 KiB
ReStructuredText
Raw Normal View History

=================================
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)::
DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-06-15 17:27:02 +08:00
<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]
<name>[-<bpp>][@<refresh>]
with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
Things between square brackets are optional.
Valid names are::
- NSTC: 480i output, with the CCIR System-M TV mode and NTSC color encoding
- NTSC-J: 480i output, with the CCIR System-M TV mode, the NTSC color
encoding, and a black level equal to the blanking level.
- PAL: 576i output, with the CCIR System-B TV mode and PAL color encoding
- PAL-M: 480i output, with the CCIR System-M TV mode and PAL color encoding
2005-09-10 04:09:58 +08:00
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
DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-06-15 17:27:02 +08:00
DRM drivers also add options to enable or disable outputs:
'e' will force the display to be enabled, i.e. it will override the detection
if a display is connected. 'D' will force the display to be enabled and use
digital output. This is useful for outputs that have both analog and digital
signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd'
is specified the output is disabled.
You can additionally specify which output the options matches to.
To force the VGA output to be enabled and drive a specific mode say::
DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-06-15 17:27:02 +08:00
video=VGA-1:1280x1024@60me
Specifying the option multiple times for different ports is possible, e.g.::
DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-06-15 17:27:02 +08:00
video=LVDS-1:d video=HDMI-1:D
Options can also be passed after the mode, using commas as separator.
Sample usage: 720x480,rotate=180 - 720x480 mode, rotated by 180 degrees
drm main pull request for v5.3-rc1 (sans mm changes) -----BEGIN PGP SIGNATURE----- iQIcBAABAgAGBQJdLMSbAAoJEAx081l5xIa+udkP/iWr8mw44tWYb8Wuzc/aR91v 02X/J4S9XTQttNn/1Gpq9ItTLMf0Gc08tk1wEBBHAWi/qGaGZS2al+rv0afeuuQa aFhQzioDi7K/YZt92iEJhdx7wVMyydICTg3INmYlSP7/FyzLp6gBQRGSJ1kX5mHZ qWsFZgUOH9V5evyB6fDMleDaqFOKfcwrD7XYwbOheL/HeYQSv5AYn3VBupBFQ76L 0hclI5VzZQ5V0nnqRTNDQVA9Yl6NTl+2eXTn5vuBtwKXEI6JJw8eihZp2oZDXqfS L441w7wGbkRPzN5kjMZjs1ToPMTlMveR5kL6Sc+o3DT/HmIr1odeaSDXR/93UOLd z0CRJ6xMC8h1ThLNHp8UgbxCKqIwYPsY2wVqjsJt7lDY5jma7Yv2YJ9ocYGHN/sO DVHcU6ugbwvuC5wZZtVZl5J4hjnBZwNRGSVK+iM0tkjalgdEuSFehXT7eQ8SphF/ yI5gD1xNEwGfZ4bvZ3u/QrDCcpUAgPIUYmxEa2tPJILQWOJ9O87yc0y9Z21k9Ef1 9yDqrFV3sPqC2xj/0ufZG/18+Yt99Ykg1jQE3RGDwD/59KAeqPbOvqTKyVODV9jE qje6ScSIc2G0713uss2bcaD3k+rCB5YL2JkKrk5OWW/T2+n9T+JFaiNh7dnSFFcU gBKyeY24OyCDMwXrby0K =SI+Y -----END PGP SIGNATURE----- Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm Pull drm updates from Dave Airlie: "The biggest thing in this is the AMD Navi GPU support, this again contains a bunch of header files that are large. These are the new AMD RX5700 GPUs that just recently became available. New drivers: - ST-Ericsson MCDE driver - Ingenic JZ47xx SoC UAPI change: - HDR source metadata property Core: - HDR inforframes and EDID parsing - drm hdmi infoframe unpacking - remove prime sg_table caching into dma-buf - New gem vram helpers to reduce driver code - Lots of drmP.h removal - reservation fencing fix - documentation updates - drm_fb_helper_connector removed - mode name command handler rewrite fbcon: - Remove the fbcon notifiers ttm: - forward progress fixes dma-buf: - make mmap call optional - debugfs refcount fixes - dma-fence free with pending signals fix - each dma-buf gets an inode Panels: - Lots of additional panel bindings amdgpu: - initial navi10 support - avoid hw reset - HDR metadata support - new thermal sensors for vega asics - RAS fixes - use HMM rather than MMU notifier - xgmi topology via kfd - SR-IOV fixes - driver reload fixes - DC use a core bpc attribute - Aux fixes for DC - Bandwidth calc updates for DC - Clock handling refactor - kfd VEGAM support vmwgfx: - Coherent memory support changes i915: - HDR Support - HDMI i2c link - Icelake multi-segmented gamma support - GuC firmware update - Mule Creek Canyon PCH support for EHL - EHL platform updtes - move i915.alpha_support to i915.force_probe - runtime PM refactoring - VBT parsing refactoring - DSI fixes - struct mutex dependency reduction - GEM code reorg mali-dp: - Komeda driver features msm: - dsi vs EPROBE_DEFER fixes - msm8998 snapdragon 835 support - a540 gpu support - mdp5 and dpu interconnect support exynos: - drmP.h removal tegra: - misc fixes tda998x: - audio support improvements - pixel repeated mode support - quantisation range handling corrections - HDMI vendor info fix armada: - interlace support fix - overlay/video plane register handling refactor - add gamma support rockchip: - RX3328 support panfrost: - expose perf counters via hidden ioctls vkms: - enumerate CRC sources list ast: - rework BO handling mgag200: - rework BO handling dw-hdmi: - suspend/resume support rcar-du: - R8A774A1 Soc Support - LVDS dual-link mode support - Additional formats - Misc fixes omapdrm: - DSI command mode display support stm - fb modifier support - runtime PM support sun4i: - use vmap ops vc4: - binner bo binding rework v3d: - compute shader support - resync/sync fixes - job management refactoring lima: - NULL pointer in irq handler fix - scheduler default timeout virtio: - fence seqno support - trace events bochs: - misc fixes tc458767: - IRQ/HDP handling sii902x: - HDMI audio support atmel-hlcdc: - misc fixes meson: - zpos support" * tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm: (1815 commits) Revert "Merge branch 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux into drm-next" Revert "mm: adjust apply_to_pfn_range interface for dropped token." mm: adjust apply_to_pfn_range interface for dropped token. drm/amdgpu/navi10: add uclk activity sensor drm/amdgpu: properly guard the generic discovery code drm/amdgpu: add missing documentation on new module parameters drm/amdgpu: don't invalidate caches in RELEASE_MEM, only do the writeback drm/amd/display: avoid 64-bit division drm/amdgpu/psp11: simplify the ucode register logic drm/amdgpu: properly guard DC support in navi code drm/amd/powerplay: vega20: fix uninitialized variable use drm/amd/display: dcn20: include linux/delay.h amdgpu: make pmu support optional drm/amd/powerplay: Zero initialize current_rpm in vega20_get_fan_speed_percent drm/amd/powerplay: Zero initialize freq in smu_v11_0_get_current_clk_freq drm/amd/powerplay: Use memset to initialize metrics structs drm/amdgpu/mes10.1: Fix header guard drm/amd/powerplay: add temperature sensor support for navi10 drm/amdgpu: fix scheduler timeout calc drm/amdgpu: Prepare for hmm_range_register API change (v2) ...
2019-07-16 10:04:27 +08:00
Valid options are::
- margin_top, margin_bottom, margin_left, margin_right (integer):
Number of pixels in the margins, typically to deal with overscan on TVs
- reflect_x (boolean): Perform an axial symmetry on the X axis
- reflect_y (boolean): Perform an axial symmetry on the Y axis
- rotate (integer): Rotate the initial framebuffer by x
degrees. Valid values are 0, 90, 180 and 270.
- tv_mode: Analog TV mode. One of "NTSC", "NTSC-443", "NTSC-J", "PAL",
"PAL-M", "PAL-N", or "SECAM".
- panel_orientation, one of "normal", "upside_down", "left_side_up", or
"right_side_up". For KMS drivers only, this sets the "panel orientation"
property on the kms connector as hint for kms users.
-----------------------------------------------------------------------------
2005-09-10 04:09:58 +08:00
What is the VESA(TM) Coordinated Video Timings (CVT)?
=====================================================
2005-09-10 04:09:58 +08:00
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)::
2005-09-10 04:09:58 +08:00
<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
2005-09-10 04:09:58 +08:00
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.
-----------------------------------------------------------------------------
2005-09-10 04:09:58 +08:00
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 drivers/video/fbdev/core/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
DRM: clean up and document parsing of video= parameter The video= parameter of the DRM drivers supports some additional flags that the normal fb drivers do not have. They also allow to limit these flags to specific outputs. Both things were previously undocumented. Also the parsing of the line had some oddities: -A lot of misplaced options were silently ignored or partly rejected instead of stopping the parsing immediately -The 'R' option is documented to follow the 'M' option if specified. It is not documented that 'M' is needed to specify 'R' (also this is the case for normal fb drivers). In fact the code is correct for normal fb drivers but wrong for DRM ones. The old code allowed 'R' only _before_ 'M' (since it parses backwards) and only if 'M' is given at all which is not needed for the DRM drivers. -the margins option ('m') was parsed but later ignored even if the later functions support it. -specifying multiple enable options at the same time did not lead to an error. -specifying something bogus for horizontal resolution (i.e. other things as digits) did not lead to an error but an invalid resolution was used. If any errors are encountered the position of the faulting string is now printed to the user and the complete mode is ignored. This gives much more consistent error behaviour. I also removed some useless assignments and changed the local flag variables to be bool. Signed-off-by: Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-06-15 17:27:02 +08:00
BTW, only a few fb drivers use this at the moment. Others are to follow
(feel free to send patches). The DRM drivers also support this.