mirror of
https://github.com/AetherDroid/android_kernel_samsung_on5xelte.git
synced 2025-09-06 16:28:04 -04:00
Fixed MTP to work with TWRP
This commit is contained in:
awab228
commit
f6dfaef42e
50820 changed files with 20846062 additions and 0 deletions
151
Documentation/fb/modedb.txt
Normal file
151
Documentation/fb/modedb.txt
Normal file
|
|
@ -0,0 +1,151 @@
|
|||
|
||||
|
||||
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
|
||||
|
||||
***** 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 fb drivers use this at the moment. Others are to follow
|
||||
(feel free to send patches). The DRM drivers also support this.
|
||||
Loading…
Add table
Add a link
Reference in a new issue