![Linus Torvalds](/assets/img/avatar_default.png)
-----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) ...
170 lines
7.3 KiB
ReStructuredText
170 lines
7.3 KiB
ReStructuredText
=================================
|
|
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][eDd]
|
|
<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
|
|
|
|
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::
|
|
|
|
video=VGA-1:1280x1024@60me
|
|
|
|
Specifying the option multiple times for different ports is possible, e.g.::
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
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.
|
|
|
|
-----------------------------------------------------------------------------
|
|
|
|
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 fb drivers use this at the moment. Others are to follow
|
|
(feel free to send patches). The DRM drivers also support this.
|