diff options
Diffstat (limited to 'Documentation/fb')
29 files changed, 1905 insertions, 688 deletions
diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX index caabbd395e6..fe85e7c5907 100644 --- a/Documentation/fb/00-INDEX +++ b/Documentation/fb/00-INDEX @@ -4,35 +4,43 @@ please mail me. Geert Uytterhoeven <geert@linux-m68k.org> 00-INDEX - - this file + - this file. +api.txt + - The frame buffer API between applications and buffer devices. arkfb.txt - info on the fbdev driver for ARK Logic chips. aty128fb.txt - info on the ATI Rage128 frame buffer driver. cirrusfb.txt - info on the driver for Cirrus Logic chipsets. -cyblafb/ - - directory with documentation files related to the cyblafb driver. +cmap_xfbdev.txt + - an introduction to fbdev's cmap structures. deferred_io.txt - an introduction to deferred IO. +efifb.txt + - info on the EFI platform driver for Intel based Apple computers. +ep93xx-fb.txt + - info on the driver for EP93xx LCD controller. fbcon.txt - intro to and usage guide for the framebuffer console (fbcon). framebuffer.txt - introduction to frame buffer devices. -imacfb.txt - - info on the generic EFI platform driver for Intel based Macs. +gxfb.txt + - info on the framebuffer driver for AMD Geode GX2 based processors. intel810.txt - documentation for the Intel 810/815 framebuffer driver. intelfb.txt - docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver. internals.txt - quick overview of frame buffer device internals. +lxfb.txt + - info on the framebuffer driver for AMD Geode LX based processors. matroxfb.txt - info on the Matrox framebuffer driver for Alpha, Intel and PPC. +metronomefb.txt + - info on the driver for the Metronome display controller. modedb.txt - info on the video mode database. -matroxfb.txt - - info on the Matrox frame buffer driver. pvr2fb.txt - info on the PowerVR 2 frame buffer driver. pxafb.txt @@ -41,13 +49,27 @@ s3fb.txt - info on the fbdev driver for S3 Trio/Virge chips. sa1100fb.txt - information about the driver for the SA-1100 LCD controller. +sh7760fb.txt + - info on the SH7760/SH7763 integrated LCDC Framebuffer driver. sisfb.txt - info on the framebuffer device driver for various SiS chips. +sm501.txt + - info on the framebuffer device driver for sm501 videoframebuffer. sstfb.txt - info on the frame buffer driver for 3dfx' Voodoo Graphics boards. tgafb.txt - - info on the TGA (DECChip 21030) frame buffer driver + - info on the TGA (DECChip 21030) frame buffer driver. +tridentfb.txt + info on the framebuffer driver for some Trident chip based cards. +udlfb.txt + - Driver for DisplayLink USB 2.0 chips. +uvesafb.txt + - info on the userspace VESA (VBE2+ compliant) frame buffer device. vesafb.txt - - info on the VESA frame buffer device + - info on the VESA frame buffer device. +viafb.modes + - list of modes for VIA Integration Graphic Chip. +viafb.txt + - info on the VIA Integration Graphic Chip console framebuffer driver. vt8623fb.txt - info on the fb driver for the graphics core in VIA VT8623 chipsets. diff --git a/Documentation/fb/api.txt b/Documentation/fb/api.txt new file mode 100644 index 00000000000..d4ff7de8570 --- /dev/null +++ b/Documentation/fb/api.txt @@ -0,0 +1,306 @@ + The Frame Buffer Device API + --------------------------- + +Last revised: June 21, 2011 + + +0. Introduction +--------------- + +This document describes the frame buffer API used by applications to interact +with frame buffer devices. In-kernel APIs between device drivers and the frame +buffer core are not described. + +Due to a lack of documentation in the original frame buffer API, drivers +behaviours differ in subtle (and not so subtle) ways. This document describes +the recommended API implementation, but applications should be prepared to +deal with different behaviours. + + +1. Capabilities +--------------- + +Device and driver capabilities are reported in the fixed screen information +capabilities field. + +struct fb_fix_screeninfo { + ... + __u16 capabilities; /* see FB_CAP_* */ + ... +}; + +Application should use those capabilities to find out what features they can +expect from the device and driver. + +- FB_CAP_FOURCC + +The driver supports the four character code (FOURCC) based format setting API. +When supported, formats are configured using a FOURCC instead of manually +specifying color components layout. + + +2. Types and visuals +-------------------- + +Pixels are stored in memory in hardware-dependent formats. Applications need +to be aware of the pixel storage format in order to write image data to the +frame buffer memory in the format expected by the hardware. + +Formats are described by frame buffer types and visuals. Some visuals require +additional information, which are stored in the variable screen information +bits_per_pixel, grayscale, red, green, blue and transp fields. + +Visuals describe how color information is encoded and assembled to create +macropixels. Types describe how macropixels are stored in memory. The following +types and visuals are supported. + +- FB_TYPE_PACKED_PIXELS + +Macropixels are stored contiguously in a single plane. If the number of bits +per macropixel is not a multiple of 8, whether macropixels are padded to the +next multiple of 8 bits or packed together into bytes depends on the visual. + +Padding at end of lines may be present and is then reported through the fixed +screen information line_length field. + +- FB_TYPE_PLANES + +Macropixels are split across multiple planes. The number of planes is equal to +the number of bits per macropixel, with plane i'th storing i'th bit from all +macropixels. + +Planes are located contiguously in memory. + +- FB_TYPE_INTERLEAVED_PLANES + +Macropixels are split across multiple planes. The number of planes is equal to +the number of bits per macropixel, with plane i'th storing i'th bit from all +macropixels. + +Planes are interleaved in memory. The interleave factor, defined as the +distance in bytes between the beginning of two consecutive interleaved blocks +belonging to different planes, is stored in the fixed screen information +type_aux field. + +- FB_TYPE_FOURCC + +Macropixels are stored in memory as described by the format FOURCC identifier +stored in the variable screen information grayscale field. + +- FB_VISUAL_MONO01 + +Pixels are black or white and stored on a number of bits (typically one) +specified by the variable screen information bpp field. + +Black pixels are represented by all bits set to 1 and white pixels by all bits +set to 0. When the number of bits per pixel is smaller than 8, several pixels +are packed together in a byte. + +FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only. + +- FB_VISUAL_MONO10 + +Pixels are black or white and stored on a number of bits (typically one) +specified by the variable screen information bpp field. + +Black pixels are represented by all bits set to 0 and white pixels by all bits +set to 1. When the number of bits per pixel is smaller than 8, several pixels +are packed together in a byte. + +FB_VISUAL_MONO01 is currently used with FB_TYPE_PACKED_PIXELS only. + +- FB_VISUAL_TRUECOLOR + +Pixels are broken into red, green and blue components, and each component +indexes a read-only lookup table for the corresponding value. Lookup tables +are device-dependent, and provide linear or non-linear ramps. + +Each component is stored in a macropixel according to the variable screen +information red, green, blue and transp fields. + +- FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR + +Pixel values are encoded as indices into a colormap that stores red, green and +blue components. The colormap is read-only for FB_VISUAL_STATIC_PSEUDOCOLOR +and read-write for FB_VISUAL_PSEUDOCOLOR. + +Each pixel value is stored in the number of bits reported by the variable +screen information bits_per_pixel field. + +- FB_VISUAL_DIRECTCOLOR + +Pixels are broken into red, green and blue components, and each component +indexes a programmable lookup table for the corresponding value. + +Each component is stored in a macropixel according to the variable screen +information red, green, blue and transp fields. + +- FB_VISUAL_FOURCC + +Pixels are encoded and interpreted as described by the format FOURCC +identifier stored in the variable screen information grayscale field. + + +3. Screen information +--------------------- + +Screen information are queried by applications using the FBIOGET_FSCREENINFO +and FBIOGET_VSCREENINFO ioctls. Those ioctls take a pointer to a +fb_fix_screeninfo and fb_var_screeninfo structure respectively. + +struct fb_fix_screeninfo stores device independent unchangeable information +about the frame buffer device and the current format. Those information can't +be directly modified by applications, but can be changed by the driver when an +application modifies the format. + +struct fb_fix_screeninfo { + char id[16]; /* identification string eg "TT Builtin" */ + unsigned long smem_start; /* Start of frame buffer mem */ + /* (physical address) */ + __u32 smem_len; /* Length of frame buffer mem */ + __u32 type; /* see FB_TYPE_* */ + __u32 type_aux; /* Interleave for interleaved Planes */ + __u32 visual; /* see FB_VISUAL_* */ + __u16 xpanstep; /* zero if no hardware panning */ + __u16 ypanstep; /* zero if no hardware panning */ + __u16 ywrapstep; /* zero if no hardware ywrap */ + __u32 line_length; /* length of a line in bytes */ + unsigned long mmio_start; /* Start of Memory Mapped I/O */ + /* (physical address) */ + __u32 mmio_len; /* Length of Memory Mapped I/O */ + __u32 accel; /* Indicate to driver which */ + /* specific chip/card we have */ + __u16 capabilities; /* see FB_CAP_* */ + __u16 reserved[2]; /* Reserved for future compatibility */ +}; + +struct fb_var_screeninfo stores device independent changeable information +about a frame buffer device, its current format and video mode, as well as +other miscellaneous parameters. + +struct fb_var_screeninfo { + __u32 xres; /* visible resolution */ + __u32 yres; + __u32 xres_virtual; /* virtual resolution */ + __u32 yres_virtual; + __u32 xoffset; /* offset from virtual to visible */ + __u32 yoffset; /* resolution */ + + __u32 bits_per_pixel; /* guess what */ + __u32 grayscale; /* 0 = color, 1 = grayscale, */ + /* >1 = FOURCC */ + struct fb_bitfield red; /* bitfield in fb mem if true color, */ + struct fb_bitfield green; /* else only length is significant */ + struct fb_bitfield blue; + struct fb_bitfield transp; /* transparency */ + + __u32 nonstd; /* != 0 Non standard pixel format */ + + __u32 activate; /* see FB_ACTIVATE_* */ + + __u32 height; /* height of picture in mm */ + __u32 width; /* width of picture in mm */ + + __u32 accel_flags; /* (OBSOLETE) see fb_info.flags */ + + /* Timing: All values in pixclocks, except pixclock (of course) */ + __u32 pixclock; /* pixel clock in ps (pico seconds) */ + __u32 left_margin; /* time from sync to picture */ + __u32 right_margin; /* time from picture to sync */ + __u32 upper_margin; /* time from sync to picture */ + __u32 lower_margin; + __u32 hsync_len; /* length of horizontal sync */ + __u32 vsync_len; /* length of vertical sync */ + __u32 sync; /* see FB_SYNC_* */ + __u32 vmode; /* see FB_VMODE_* */ + __u32 rotate; /* angle we rotate counter clockwise */ + __u32 colorspace; /* colorspace for FOURCC-based modes */ + __u32 reserved[4]; /* Reserved for future compatibility */ +}; + +To modify variable information, applications call the FBIOPUT_VSCREENINFO +ioctl with a pointer to a fb_var_screeninfo structure. If the call is +successful, the driver will update the fixed screen information accordingly. + +Instead of filling the complete fb_var_screeninfo structure manually, +applications should call the FBIOGET_VSCREENINFO ioctl and modify only the +fields they care about. + + +4. Format configuration +----------------------- + +Frame buffer devices offer two ways to configure the frame buffer format: the +legacy API and the FOURCC-based API. + + +The legacy API has been the only frame buffer format configuration API for a +long time and is thus widely used by application. It is the recommended API +for applications when using RGB and grayscale formats, as well as legacy +non-standard formats. + +To select a format, applications set the fb_var_screeninfo bits_per_pixel field +to the desired frame buffer depth. Values up to 8 will usually map to +monochrome, grayscale or pseudocolor visuals, although this is not required. + +- For grayscale formats, applications set the grayscale field to one. The red, + blue, green and transp fields must be set to 0 by applications and ignored by + drivers. Drivers must fill the red, blue and green offsets to 0 and lengths + to the bits_per_pixel value. + +- For pseudocolor formats, applications set the grayscale field to zero. The + red, blue, green and transp fields must be set to 0 by applications and + ignored by drivers. Drivers must fill the red, blue and green offsets to 0 + and lengths to the bits_per_pixel value. + +- For truecolor and directcolor formats, applications set the grayscale field + to zero, and the red, blue, green and transp fields to describe the layout of + color components in memory. + +struct fb_bitfield { + __u32 offset; /* beginning of bitfield */ + __u32 length; /* length of bitfield */ + __u32 msb_right; /* != 0 : Most significant bit is */ + /* right */ +}; + + Pixel values are bits_per_pixel wide and are split in non-overlapping red, + green, blue and alpha (transparency) components. Location and size of each + component in the pixel value are described by the fb_bitfield offset and + length fields. Offset are computed from the right. + + Pixels are always stored in an integer number of bytes. If the number of + bits per pixel is not a multiple of 8, pixel values are padded to the next + multiple of 8 bits. + +Upon successful format configuration, drivers update the fb_fix_screeninfo +type, visual and line_length fields depending on the selected format. + + +The FOURCC-based API replaces format descriptions by four character codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define a format +without explicitly describing it. This is the only API that supports YUV +formats. Drivers are also encouraged to implement the FOURCC-based API for RGB +and grayscale formats. + +Drivers that support the FOURCC-based API report this capability by setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities field. + +FOURCC definitions are located in the linux/videodev2.h header. However, and +despite starting with the V4L2_PIX_FMT_prefix, they are not restricted to V4L2 +and don't require usage of the V4L2 subsystem. FOURCC documentation is +available in Documentation/DocBook/v4l/pixfmt.xml. + +To select a format, applications set the grayscale field to the desired FOURCC. +For YUV formats, they should also select the appropriate colorspace by setting +the colorspace field to one of the colorspaces listed in linux/videodev2.h and +documented in Documentation/DocBook/v4l/colorspaces.xml. + +The red, green, blue and transp fields are not used with the FOURCC-based API. +For forward compatibility reasons applications must zero those fields, and +drivers must ignore them. Values other than 0 may get a meaning in future +extensions. + +Upon successful format configuration, drivers update the fb_fix_screeninfo +type, visual and line_length fields depending on the selected format. The type +and visual fields are set to FB_TYPE_FOURCC and FB_VISUAL_FOURCC respectively. diff --git a/Documentation/fb/cirrusfb.txt b/Documentation/fb/cirrusfb.txt index f9436843e99..f75950d330a 100644 --- a/Documentation/fb/cirrusfb.txt +++ b/Documentation/fb/cirrusfb.txt @@ -55,7 +55,7 @@ Version 1.9.4.4 * Overhaul color register routines. * Associated with the above, console colors are now obtained from a LUT called 'palette' instead of from the VGA registers. This code was - modeled after that in atyfb and matroxfb. + modelled after that in atyfb and matroxfb. * Code cleanup, add comments. * Overhaul SR07 handling. * Bug fixes. diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs deleted file mode 100644 index 9443a6d72cd..00000000000 --- a/Documentation/fb/cyblafb/bugs +++ /dev/null @@ -1,13 +0,0 @@ -Bugs -==== - -I currently don't know of any bug. Please do send reports to: - - linux-fbdev-devel@lists.sourceforge.net - - Knut_Petersen@t-online.de. - - -Untested features -================= - -All LCD stuff is untested. If it worked in tridentfb, it should work in -cyblafb. Please test and report the results to Knut_Petersen@t-online.de. diff --git a/Documentation/fb/cyblafb/credits b/Documentation/fb/cyblafb/credits deleted file mode 100644 index 0eb3b443dc2..00000000000 --- a/Documentation/fb/cyblafb/credits +++ /dev/null @@ -1,7 +0,0 @@ -Thanks to -========= - * Alan Hourihane, for writing the X trident driver - * Jani Monoses, for writing the tridentfb driver - * Antonino A. Daplas, for review of the first published - version of cyblafb and some code - * Jochen Hein, for testing and a helpfull bug report diff --git a/Documentation/fb/cyblafb/documentation b/Documentation/fb/cyblafb/documentation deleted file mode 100644 index bb1aac04842..00000000000 --- a/Documentation/fb/cyblafb/documentation +++ /dev/null @@ -1,17 +0,0 @@ -Available Documentation -======================= - -Apollo PLE 133 Chipset VT8601A North Bridge Datasheet, Rev. 1.82, October 22, -2001, available from VIA: - - http://www.viavpsd.com/product/6/15/DS8601A182.pdf - -The datasheet is incomplete, some registers that need to be programmed are not -explained at all and important bits are listed as "reserved". But you really -need the datasheet to understand the code. "p. xxx" comments refer to page -numbers of this document. - -XFree/XOrg drivers are available and of good quality, looking at the code -there is a good idea if the datasheet does not provide enough information -or if the datasheet seems to be wrong. - diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes deleted file mode 100644 index fe0e5223ba8..00000000000 --- a/Documentation/fb/cyblafb/fb.modes +++ /dev/null @@ -1,154 +0,0 @@ -# -# Sample fb.modes file -# -# Provides an incomplete list of working modes for -# the cyberblade/i1 graphics core. -# -# The value 4294967256 is used instead of -40. Of course, -40 is not -# a really reasonable value, but chip design does not always follow -# logic. Believe me, it's ok, and it's the way the BIOS does it. -# -# fbset requires 4294967256 in fb.modes and -40 as an argument to -# the -t parameter. That's also not too reasonable, and it might change -# in the future or might even be differt for your current version. -# - -mode "640x480-50" - geometry 640 480 2048 4096 8 - timings 47619 4294967256 24 17 0 216 3 -endmode - -mode "640x480-60" - geometry 640 480 2048 4096 8 - timings 39682 4294967256 24 17 0 216 3 -endmode - -mode "640x480-70" - geometry 640 480 2048 4096 8 - timings 34013 4294967256 24 17 0 216 3 -endmode - -mode "640x480-72" - geometry 640 480 2048 4096 8 - timings 33068 4294967256 24 17 0 216 3 -endmode - -mode "640x480-75" - geometry 640 480 2048 4096 8 - timings 31746 4294967256 24 17 0 216 3 -endmode - -mode "640x480-80" - geometry 640 480 2048 4096 8 - timings 29761 4294967256 24 17 0 216 3 -endmode - -mode "640x480-85" - geometry 640 480 2048 4096 8 - timings 28011 4294967256 24 17 0 216 3 -endmode - -mode "800x600-50" - geometry 800 600 2048 4096 8 - timings 30303 96 24 14 0 136 11 -endmode - -mode "800x600-60" - geometry 800 600 2048 4096 8 - timings 25252 96 24 14 0 136 11 -endmode - -mode "800x600-70" - geometry 800 600 2048 4096 8 - timings 21645 96 24 14 0 136 11 -endmode - -mode "800x600-72" - geometry 800 600 2048 4096 8 - timings 21043 96 24 14 0 136 11 -endmode - -mode "800x600-75" - geometry 800 600 2048 4096 8 - timings 20202 96 24 14 0 136 11 -endmode - -mode "800x600-80" - geometry 800 600 2048 4096 8 - timings 18939 96 24 14 0 136 11 -endmode - -mode "800x600-85" - geometry 800 600 2048 4096 8 - timings 17825 96 24 14 0 136 11 -endmode - -mode "1024x768-50" - geometry 1024 768 2048 4096 8 - timings 19054 144 24 29 0 120 3 -endmode - -mode "1024x768-60" - geometry 1024 768 2048 4096 8 - timings 15880 144 24 29 0 120 3 -endmode - -mode "1024x768-70" - geometry 1024 768 2048 4096 8 - timings 13610 144 24 29 0 120 3 -endmode - -mode "1024x768-72" - geometry 1024 768 2048 4096 8 - timings 13232 144 24 29 0 120 3 -endmode - -mode "1024x768-75" - geometry 1024 768 2048 4096 8 - timings 12703 144 24 29 0 120 3 -endmode - -mode "1024x768-80" - geometry 1024 768 2048 4096 8 - timings 11910 144 24 29 0 120 3 -endmode - -mode "1024x768-85" - geometry 1024 768 2048 4096 8 - timings 11209 144 24 29 0 120 3 -endmode - -mode "1280x1024-50" - geometry 1280 1024 2048 4096 8 - timings 11114 232 16 39 0 160 3 -endmode - -mode "1280x1024-60" - geometry 1280 1024 2048 4096 8 - timings 9262 232 16 39 0 160 3 -endmode - -mode "1280x1024-70" - geometry 1280 1024 2048 4096 8 - timings 7939 232 16 39 0 160 3 -endmode - -mode "1280x1024-72" - geometry 1280 1024 2048 4096 8 - timings 7719 232 16 39 0 160 3 -endmode - -mode "1280x1024-75" - geometry 1280 1024 2048 4096 8 - timings 7410 232 16 39 0 160 3 -endmode - -mode "1280x1024-80" - geometry 1280 1024 2048 4096 8 - timings 6946 232 16 39 0 160 3 -endmode - -mode "1280x1024-85" - geometry 1280 1024 2048 4096 8 - timings 6538 232 16 39 0 160 3 -endmode diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance deleted file mode 100644 index 8d15d5dfc6b..00000000000 --- a/Documentation/fb/cyblafb/performance +++ /dev/null @@ -1,79 +0,0 @@ -Speed -===== - -CyBlaFB is much faster than tridentfb and vesafb. Compare the performance data -for mode 1280x1024-[8,16,32]@61 Hz. - -Test 1: Cat a file with 2000 lines of 0 characters. -Test 2: Cat a file with 2000 lines of 80 characters. -Test 3: Cat a file with 2000 lines of 160 characters. - -All values show system time use in seconds, kernel 2.6.12 was used for -the measurements. 2.6.13 is a bit slower, 2.6.14 hopefully will include a -patch that speeds up kernel bitblitting a lot ( > 20%). - -+-----------+-----------------------------------------------------+ -| | not accelerated | -| TRIDENTFB +-----------------+-----------------+-----------------+ -| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | -| | noypan | ypan | noypan | ypan | noypan | ypan | -+-----------+--------+--------+--------+--------+--------+--------+ -| Test 1 | 4.31 | 4.33 | 6.05 | 12.81 | ---- | ---- | -| Test 2 | 67.94 | 5.44 | 123.16 | 14.79 | ---- | ---- | -| Test 3 | 131.36 | 6.55 | 240.12 | 16.76 | ---- | ---- | -+-----------+--------+--------+--------+--------+--------+--------+ -| Comments | | | completely bro- | -| | | | ken, monitor | -| | | | switches off | -+-----------+-----------------+-----------------+-----------------+ - - -+-----------+-----------------------------------------------------+ -| | accelerated | -| TRIDENTFB +-----------------+-----------------+-----------------+ -| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | -| | noypan | ypan | noypan | ypan | noypan | ypan | -+-----------+--------+--------+--------+--------+--------+--------+ -| Test 1 | ---- | ---- | 20.62 | 1.22 | ---- | ---- | -| Test 2 | ---- | ---- | 22.61 | 3.19 | ---- | ---- | -| Test 3 | ---- | ---- | 24.59 | 5.16 | ---- | ---- | -+-----------+--------+--------+--------+--------+--------+--------+ -| Comments | broken, writing | broken, ok only | completely bro- | -| | to wrong places | if bgcolor is | ken, monitor | -| | on screen + bug | black, bug in | switches off | -| | in fillrect() | fillrect() | | -+-----------+-----------------+-----------------+-----------------+ - - -+-----------+-----------------------------------------------------+ -| | not accelerated | -| VESAFB +-----------------+-----------------+-----------------+ -| of 2.6.12 | 8 bpp | 16 bpp | 32 bpp | -| | noypan | ypan | noypan | ypan | noypan | ypan | -+-----------+--------+--------+--------+--------+--------+--------+ -| Test 1 | 4.26 | 3.76 | 5.99 | 7.23 | ---- | ---- | -| Test 2 | 65.65 | 4.89 | 120.88 | 9.08 | ---- | ---- | -| Test 3 | 126.91 | 5.94 | 235.77 | 11.03 | ---- | ---- | -+-----------+--------+--------+--------+--------+--------+--------+ -| Comments | vga=0x307 | vga=0x31a | vga=0x31b not | -| | fh=80kHz | fh=80kHz | supported by | -| | fv=75kHz | fv=75kHz | video BIOS and | -| | | | hardware | -+-----------+-----------------+-----------------+-----------------+ - - -+-----------+-----------------------------------------------------+ -| | accelerated | -| CYBLAFB +-----------------+-----------------+-----------------+ -| | 8 bpp | 16 bpp | 32 bpp | -| | noypan | ypan | noypan | ypan | noypan | ypan | -+-----------+--------+--------+--------+--------+--------+--------+ -| Test 1 | 8.02 | 0.23 | 19.04 | 0.61 | 57.12 | 2.74 | -| Test 2 | 8.38 | 0.55 | 19.39 | 0.92 | 57.54 | 3.13 | -| Test 3 | 8.73 | 0.86 | 19.74 | 1.24 | 57.95 | 3.51 | -+-----------+--------+--------+--------+--------+--------+--------+ -| Comments | | | | -| | | | | -| | | | | -| | | | | -+-----------+-----------------+-----------------+-----------------+ diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo deleted file mode 100644 index c5f6d0eae54..00000000000 --- a/Documentation/fb/cyblafb/todo +++ /dev/null @@ -1,31 +0,0 @@ -TODO / Missing features -======================= - -Verify LCD stuff "stretch" and "center" options are - completely untested ... this code needs to be - verified. As I don't have access to such - hardware, please contact me if you are - willing run some tests. - -Interlaced video modes The reason that interleaved - modes are disabled is that I do not know - the meaning of the vertical interlace - parameter. Also the datasheet mentions a - bit d8 of a horizontal interlace parameter, - but nowhere the lower 8 bits. Please help - if you can. - -low-res double scan modes Who needs it? - -accelerated color blitting Who needs it? The console driver does use color - blitting for nothing but drawing the penguine, - everything else is done using color expanding - blitting of 1bpp character bitmaps. - -ioctls Who needs it? - -TV-out Will be done later. Use "vga= " at boot time - to set a suitable video mode. - -??? Feel free to contact me if you have any - feature requests diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage deleted file mode 100644 index a39bb3d402a..00000000000 --- a/Documentation/fb/cyblafb/usage +++ /dev/null @@ -1,217 +0,0 @@ -CyBlaFB is a framebuffer driver for the Cyberblade/i1 graphics core integrated -into the VIA Apollo PLE133 (aka vt8601) south bridge. It is developed and -tested using a VIA EPIA 5000 board. - -Cyblafb - compiled into the kernel or as a module? -================================================== - -You might compile cyblafb either as a module or compile it permanently into the -kernel. - -Unless you have a real reason to do so you should not compile both vesafb and -cyblafb permanently into the kernel. It's possible and it helps during the -developement cycle, but it's useless and will at least block some otherwise -usefull memory for ordinary users. - -Selecting Modes -=============== - - Startup Mode - ============ - - First of all, you might use the "vga=???" boot parameter as it is - documented in vesafb.txt and svga.txt. Cyblafb will detect the video - mode selected and will use the geometry and timings found by - inspecting the hardware registers. - - video=cyblafb vga=0x317 - - Alternatively you might use a combination of the mode, ref and bpp - parameters. If you compiled the driver into the kernel, add something - like this to the kernel command line: - - video=cyblafb:1280x1024,bpp=16,ref=50 ... - - If you compiled the driver as a module, the same mode would be - selected by the following command: - - modprobe cyblafb mode=1280x1024 bpp=16 ref=50 ... - - None of the modes possible to select as startup modes are affected by - the problems described at the end of the next subsection. - - For all startup modes cyblafb chooses a virtual x resolution of 2048, - the only exception is mode 1280x1024 in combination with 32 bpp. This - allows ywrap scrolling for all those modes if rotation is 0 or 2, and - also fast scrolling if rotation is 1 or 3. The default virtual y reso- - lution is 4096 for bpp == 8, 2048 for bpp==16 and 1024 for bpp == 32, - again with the only exception of 1280x1024 at 32 bpp. - - Please do set your video memory size to 8 Mb in the Bios setup. Other - values will work, but performace is decreased for a lot of modes. - - Mode changes using fbset - ======================== - - You might use fbset to change the video mode, see "man fbset". Cyblafb - generally does assume that you know what you are doing. But it does - some checks, especially those that are needed to prevent you from - damaging your hardware. - - - only 8, 16, 24 and 32 bpp video modes are accepted - - interlaced video modes are not accepted - - double scan video modes are not accepted - - if a flat panel is found, cyblafb does not allow you - to program a resolution higher than the physical - resolution of the flat panel monitor - - cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp - and (currently) 24 bit modes use a doubled vclk internally, - the dotclock limit as seen by fbset is 115 MHz for those - modes and 230 MHz for 8 and 16 bpp modes. - - cyblafb will allow you to select very high resolutions as - long as the hardware can be programmed to these modes. The - documented limit 1600x1200 is not enforced, but don't expect - perfect signal quality. - - Any request that violates the rules given above will be either changed - to something the hardware supports or an error value will be returned. - - If you program a virtual y resolution higher than the hardware limit, - cyblafb will silently decrease that value to the highest possible - value. The same is true for a virtual x resolution that is not - supported by the hardware. Cyblafb tries to adapt vyres first because - vxres decides if ywrap scrolling is possible or not. - - Attempts to disable acceleration are ignored, I believe that this is - safe. - - Some video modes that should work do not work as expected. If you use - the standard fb.modes, fbset 640x480-60 will program that mode, but - you will see a vertical area, about two characters wide, with only - much darker characters than the other characters on the screen. - Cyblafb does allow that mode to be set, as it does not violate the - official specifications. It would need a lot of code to reliably sort - out all invalid modes, playing around with the margin values will - give a valid mode quickly. And if cyblafb would detect such an invalid - mode, should it silently alter the requested values or should it - report an error? Both options have some pros and cons. As stated - above, none of the startup modes are affected, and if you set - verbosity to 1 or higher, cyblafb will print the fbset command that - would be needed to program that mode using fbset. - - -Other Parameters -================ - - -crt don't autodetect, assume monitor connected to - standard VGA connector - -fp don't autodetect, assume flat panel display - connected to flat panel monitor interface - -nativex inform driver about native x resolution of - flat panel monitor connected to special - interface (should be autodetected) - -stretch stretch image to adapt low resolution modes to - higer resolutions of flat panel monitors - connected to special interface - -center center image to adapt low resolution modes to - higer resolutions of flat panel monitors - connected to special interface - -memsize use if autodetected memsize is wrong ... - should never be necessary - -nopcirr disable PCI read retry -nopciwr disable PCI write retry -nopcirb disable PCI read bursts -nopciwb disable PCI write bursts - -bpp bpp for specified modes - valid values: 8 || 16 || 24 || 32 - -ref refresh rate for specified mode - valid values: 50 <= ref <= 85 - -mode 640x480 or 800x600 or 1024x768 or 1280x1024 - if not specified, the startup mode will be detected - and used, so you might also use the vga=??? parameter - described in vesafb.txt. If you do not specify a mode, - bpp and ref parameters are ignored. - -verbosity 0 is the default, increase to at least 2 for every - bug report! - -Development hints -================= - -It's much faster do compile a module and to load the new version after -unloading the old module than to compile a new kernel and to reboot. So if you -try to work on cyblafb, it might be a good idea to use cyblafb as a module. -In real life, fast often means dangerous, and that's also the case here. If -you introduce a serious bug when cyblafb is compiled into the kernel, the -kernel will lock or oops with a high probability before the file system is -mounted, and the danger for your data is low. If you load a broken own version -of cyblafb on a running system, the danger for the integrity of the file -system is much higher as you might need a hard reset afterwards. Decide -yourself. - -Module unloading, the vfb method -================================ - -If you want to unload/reload cyblafb using the virtual framebuffer, you need -to enable vfb support in the kernel first. After that, load the modules as -shown below: - - modprobe vfb vfb_enable=1 - modprobe fbcon - modprobe cyblafb - fbset -fb /dev/fb1 1280x1024-60 -vyres 2662 - con2fb /dev/fb1 /dev/tty1 - ... - -If you now made some changes to cyblafb and want to reload it, you might do it -as show below: - - con2fb /dev/fb0 /dev/tty1 - ... - rmmod cyblafb - modprobe cyblafb - con2fb /dev/fb1 /dev/tty1 - ... - -Of course, you might choose another mode, and most certainly you also want to -map some other /dev/tty* to the real framebuffer device. You might also choose -to compile fbcon as a kernel module or place it permanently in the kernel. - -I do not know of any way to unload fbcon, and fbcon will prevent the -framebuffer device loaded first from unloading. [If there is a way, then -please add a description here!] - -Module unloading, the vesafb method -=================================== - -Configure the kernel: - - <*> Support for frame buffer devices - [*] VESA VGA graphics support - <M> Cyberblade/i1 support - -Add e.g. "video=vesafb:ypan vga=0x307" to the kernel parameters. The ypan -parameter is important, choose any vga parameter you like as long as it is -a graphics mode. - -After booting, load cyblafb without any mode and bpp parameter and assign -cyblafb to individual ttys using con2fb, e.g.: - - modprobe cyblafb - con2fb /dev/fb1 /dev/tty1 - -Unloading cyblafb works without problems after you assign vesafb to all -ttys again, e.g.: - - con2fb /dev/fb0 /dev/tty1 - rmmod cyblafb diff --git a/Documentation/fb/cyblafb/whatsnew b/Documentation/fb/cyblafb/whatsnew deleted file mode 100644 index 76c07a26e04..00000000000 --- a/Documentation/fb/cyblafb/whatsnew +++ /dev/null @@ -1,29 +0,0 @@ -0.62 -==== - - - the vesafb parameter has been removed as I decided to allow the - feature without any special parameter. - - - Cyblafb does not use the vga style of panning any longer, now the - "right view" register in the graphics engine IO space is used. Without - that change it was impossible to use all available memory, and without - access to all available memory it is impossible to ywrap. - - - The imageblit function now uses hardware acceleration for all font - widths. Hardware blitting across pixel column 2048 is broken in the - cyberblade/i1 graphics core, but we work around that hardware bug. - - - modes with vxres != xres are supported now. - - - ywrap scrolling is supported now and the default. This is a big - performance gain. - - - default video modes use vyres > yres and vxres > xres to allow - almost optimal scrolling speed for normal and rotated screens - - - some features mainly usefull for debugging the upper layers of the - framebuffer system have been added, have a look at the code - - - fixed: Oops after unloading cyblafb when reading /proc/io* - - - we work around some bugs of the higher framebuffer layers. diff --git a/Documentation/fb/cyblafb/whycyblafb b/Documentation/fb/cyblafb/whycyblafb deleted file mode 100644 index a123bc11e69..00000000000 --- a/Documentation/fb/cyblafb/whycyblafb +++ /dev/null @@ -1,85 +0,0 @@ -I tried the following framebuffer drivers: - - - TRIDENTFB is full of bugs. Acceleration is broken for Blade3D - graphics cores like the cyberblade/i1. It claims to support a great - number of devices, but documentation for most of these devices is - unfortunately not available. There is _no_ reason to use tridentfb - for cyberblade/i1 + CRT users. VESAFB is faster, and the one - advantage, mode switching, is broken in tridentfb. - - - VESAFB is used by many distributions as a standard. Vesafb does - not support mode switching. VESAFB is a bit faster than the working - configurations of TRIDENTFB, but it is still too slow, even if you - use ypan. - - - EPIAFB (you'll find it on sourceforge) supports the Cyberblade/i1 - graphics core, but it still has serious bugs and developement seems - to have stopped. This is the one driver with TV-out support. If you - do need this feature, try epiafb. - -None of these drivers was a real option for me. - -I believe that is unreasonable to change code that announces to support 20 -devices if I only have more or less sufficient documentation for exactly one -of these. The risk of breaking device foo while fixing device bar is too high. - -So I decided to start CyBlaFB as a stripped down tridentfb. - -All code specific to other Trident chips has been removed. After that there -were a lot of cosmetic changes to increase the readability of the code. All -register names were changed to those mnemonics used in the datasheet. Function -and macro names were changed if they hindered easy understanding of the code. - -After that I debugged the code and implemented some new features. I'll try to -give a little summary of the main changes: - - - calculation of vertical and horizontal timings was fixed - - - video signal quality has been improved dramatically - - - acceleration: - - - fillrect and copyarea were fixed and reenabled - - - color expanding imageblit was newly implemented, color - imageblit (only used to draw the penguine) still uses the - generic code. - - - init of the acceleration engine was improved and moved to a - place where it really works ... - - - sync function has a timeout now and tries to reset and - reinit the accel engine if necessary - - - fewer slow copyarea calls when doing ypan scrolling by using - undocumented bit d21 of screen start address stored in - CR2B[5]. BIOS does use it also, so this should be safe. - - - cyblafb rejects any attempt to set modes that would cause vclk - values above reasonable 230 MHz. 32bit modes use a clock - multiplicator of 2, so fbset does show the correct values for - pixclock but not for vclk in this case. The fbset limit is 115 MHz - for 32 bpp modes. - - - cyblafb rejects modes known to be broken or unimplemented (all - interlaced modes, all doublescan modes for now) - - - cyblafb now works independant of the video mode in effect at startup - time (tridentfb does not init all needed registers to reasonable - values) - - - switching between video modes does work reliably now - - - the first video mode now is the one selected on startup using the - vga=???? mechanism or any of - - 640x480, 800x600, 1024x768, 1280x1024 - - 8, 16, 24 or 32 bpp - - refresh between 50 Hz and 85 Hz, 1 Hz steps (1280x1024-32 - is limited to 63Hz) - - - pci retry and pci burst mode are settable (try to disable if you - experience latency problems) - - - built as a module cyblafb might be unloaded and reloaded using - the vfb module and con2vt or might be used together with vesafb - diff --git a/Documentation/fb/imacfb.txt b/Documentation/fb/efifb.txt index 316ec9bb7de..a59916c29b3 100644 --- a/Documentation/fb/imacfb.txt +++ b/Documentation/fb/efifb.txt @@ -1,9 +1,9 @@ -What is imacfb? +What is efifb? =============== This is a generic EFI platform driver for Intel based Apple computers. -Imacfb is only for EFI booted Intel Macs. +efifb is only for EFI booted Intel Macs. Supported Hardware ================== @@ -16,16 +16,16 @@ MacMini How to use it? ============== -Imacfb does not have any kind of autodetection of your machine. +efifb does not have any kind of autodetection of your machine. You have to add the following kernel parameters in your elilo.conf: Macbook : - video=imacfb:macbook + video=efifb:macbook MacMini : - video=imacfb:mini + video=efifb:mini Macbook Pro 15", iMac 17" : - video=imacfb:i17 + video=efifb:i17 Macbook Pro 17", iMac 20" : - video=imacfb:i20 + video=efifb:i20 -- Edgar Hucek <gimli@dark-green.com> diff --git a/Documentation/fb/ep93xx-fb.txt b/Documentation/fb/ep93xx-fb.txt new file mode 100644 index 00000000000..5af1bd9effa --- /dev/null +++ b/Documentation/fb/ep93xx-fb.txt @@ -0,0 +1,135 @@ +================================ +Driver for EP93xx LCD controller +================================ + +The EP93xx LCD controller can drive both standard desktop monitors and +embedded LCD displays. If you have a standard desktop monitor then you +can use the standard Linux video mode database. In your board file: + + static struct ep93xxfb_mach_info some_board_fb_info = { + .num_modes = EP93XXFB_USE_MODEDB, + .bpp = 16, + }; + +If you have an embedded LCD display then you need to define a video +mode for it as follows: + + static struct fb_videomode some_board_video_modes[] = { + { + .name = "some_lcd_name", + /* Pixel clock, porches, etc */ + }, + }; + +Note that the pixel clock value is in pico-seconds. You can use the +KHZ2PICOS macro to convert the pixel clock value. Most other values +are in pixel clocks. See Documentation/fb/framebuffer.txt for further +details. + +The ep93xxfb_mach_info structure for your board should look like the +following: + + static struct ep93xxfb_mach_info some_board_fb_info = { + .num_modes = ARRAY_SIZE(some_board_video_modes), + .modes = some_board_video_modes, + .default_mode = &some_board_video_modes[0], + .bpp = 16, + }; + +The framebuffer device can be registered by adding the following to +your board initialisation function: + + ep93xx_register_fb(&some_board_fb_info); + +===================== +Video Attribute Flags +===================== + +The ep93xxfb_mach_info structure has a flags field which can be used +to configure the controller. The video attributes flags are fully +documented in section 7 of the EP93xx users' guide. The following +flags are available: + +EP93XXFB_PCLK_FALLING Clock data on the falling edge of the + pixel clock. The default is to clock + data on the rising edge. + +EP93XXFB_SYNC_BLANK_HIGH Blank signal is active high. By + default the blank signal is active low. + +EP93XXFB_SYNC_HORIZ_HIGH Horizontal sync is active high. By + default the horizontal sync is active low. + +EP93XXFB_SYNC_VERT_HIGH Vertical sync is active high. By + default the vertical sync is active high. + +The physical address of the framebuffer can be controlled using the +following flags: + +EP93XXFB_USE_SDCSN0 Use SDCSn[0] for the framebuffer. This + is the default setting. + +EP93XXFB_USE_SDCSN1 Use SDCSn[1] for the framebuffer. + +EP93XXFB_USE_SDCSN2 Use SDCSn[2] for the framebuffer. + +EP93XXFB_USE_SDCSN3 Use SDCSn[3] for the framebuffer. + +================== +Platform callbacks +================== + +The EP93xx framebuffer driver supports three optional platform +callbacks: setup, teardown and blank. The setup and teardown functions +are called when the framebuffer driver is installed and removed +respectively. The blank function is called whenever the display is +blanked or unblanked. + +The setup and teardown devices pass the platform_device structure as +an argument. The fb_info and ep93xxfb_mach_info structures can be +obtained as follows: + + static int some_board_fb_setup(struct platform_device *pdev) + { + struct ep93xxfb_mach_info *mach_info = pdev->dev.platform_data; + struct fb_info *fb_info = platform_get_drvdata(pdev); + + /* Board specific framebuffer setup */ + } + +====================== +Setting the video mode +====================== + +The video mode is set using the following syntax: + + video=XRESxYRES[-BPP][@REFRESH] + +If the EP93xx video driver is built-in then the video mode is set on +the Linux kernel command line, for example: + + video=ep93xx-fb:800x600-16@60 + +If the EP93xx video driver is built as a module then the video mode is +set when the module is installed: + + modprobe ep93xx-fb video=320x240 + +============== +Screenpage bug +============== + +At least on the EP9315 there is a silicon bug which causes bit 27 of +the VIDSCRNPAGE (framebuffer physical offset) to be tied low. There is +an unofficial errata for this bug at: + http://marc.info/?l=linux-arm-kernel&m=110061245502000&w=2 + +By default the EP93xx framebuffer driver checks if the allocated physical +address has bit 27 set. If it does, then the memory is freed and an +error is returned. The check can be disabled by adding the following +option when loading the driver: + + ep93xx-fb.check_screenpage_bug=0 + +In some cases it may be possible to reconfigure your SDRAM layout to +avoid this bug. See section 13 of the EP93xx users' guide for details. diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt index 99ea58e65ef..4a9739abc86 100644 --- a/Documentation/fb/fbcon.txt +++ b/Documentation/fb/fbcon.txt @@ -150,7 +150,7 @@ C. Boot options C. Attaching, Detaching and Unloading -Before going on on how to attach, detach and unload the framebuffer console, an +Before going on how to attach, detach and unload the framebuffer console, an illustration of the dependencies may help. The console layer, as with most subsystems, needs a driver that interfaces with diff --git a/Documentation/fb/framebuffer.txt b/Documentation/fb/framebuffer.txt index b3e3a035683..58c5ae2e9f5 100644 --- a/Documentation/fb/framebuffer.txt +++ b/Documentation/fb/framebuffer.txt @@ -312,10 +312,8 @@ and to the following documentation: 8. Mailing list --------------- -There are several frame buffer device related mailing lists at SourceForge: - - linux-fbdev-announce@lists.sourceforge.net, for announcements, - - linux-fbdev-user@lists.sourceforge.net, for generic user support, - - linux-fbdev-devel@lists.sourceforge.net, for project developers. +There is a frame buffer device related mailing list at kernel.org: +linux-fbdev@vger.kernel.org. Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for subscription information and archive browsing. @@ -332,7 +330,7 @@ and on its mirrors. The latest version of fbset can be found at - http://home.tvd.be/cr26864/Linux/fbdev/ + http://www.linux-fbdev.org/ 10. Credits diff --git a/Documentation/fb/intel810.txt b/Documentation/fb/intel810.txt index be3e7836abe..a8e9f5bca6f 100644 --- a/Documentation/fb/intel810.txt +++ b/Documentation/fb/intel810.txt @@ -211,7 +211,7 @@ Using the same setup as described above, load the module like this: modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \ vsync2=85 accel=1 mtrr=1 -Or just add the following to /etc/modprobe.conf +Or just add the following to a configuration file in /etc/modprobe.d/ options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \ vsync2=85 accel=1 mtrr=1 diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt index 27a3160650a..feac4e4d696 100644 --- a/Documentation/fb/intelfb.txt +++ b/Documentation/fb/intelfb.txt @@ -14,6 +14,7 @@ graphics devices. These would include: Intel 915GM Intel 945G Intel 945GM + Intel 945GME Intel 965G Intel 965GM @@ -119,7 +120,7 @@ Using the same setup as described above, load the module like this: modprobe intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1 -Or just add the following to /etc/modprobe.conf +Or just add the following to a configuration file in /etc/modprobe.d/ options intelfb mode=800x600-32@75 vram=8 accel=1 hwcursor=1 diff --git a/Documentation/fb/matroxfb.txt b/Documentation/fb/matroxfb.txt index ad7a67707d6..b95f5bb522f 100644 --- a/Documentation/fb/matroxfb.txt +++ b/Documentation/fb/matroxfb.txt @@ -177,8 +177,8 @@ sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no effect without `init'. sdram - tells to driver that you have Gxx0 with SDRAM memory. It is a default. -inv24 - change timings parameters for 24bpp modes on Millenium and - Millenium II. Specify this if you see strange color shadows around +inv24 - change timings parameters for 24bpp modes on Millennium and + Millennium II. Specify this if you see strange color shadows around characters. noinv24 - use standard timings. It is the default. inverse - invert colors on screen (for LCD displays) @@ -186,9 +186,7 @@ noinverse - show true colors on screen. It is default. dev:X - bind driver to device X. Driver numbers device from 0 up to N, where device 0 is first `known' device found, 1 second and so on. lspci lists devices in this order. - Default is `every' known device for driver with multihead support - and first working device (usually dev:0) for driver without - multihead support. + Default is `every' known device. nohwcursor - disables hardware cursor (use software cursor instead). hwcursor - enables hardware cursor. It is default. If you are using non-accelerated mode (`noaccel' or `fbset -accel false'), software @@ -206,9 +204,9 @@ grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text, can paint colors. nograyscale - disable grayscale summing. It is default. cross4MB - enables that pixel line can cross 4MB boundary. It is default for - non-Millenium. + non-Millennium. nocross4MB - pixel line must not cross 4MB boundary. It is default for - Millenium I or II, because of these devices have hardware + Millennium I or II, because of these devices have hardware limitations which do not allow this. But this option is incompatible with some (if not all yet released) versions of XF86_FBDev. diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt index ec4dee75a35..16aa0845391 100644 --- a/Documentation/fb/modedb.txt +++ b/Documentation/fb/modedb.txt @@ -20,7 +20,7 @@ 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] + <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. @@ -36,6 +36,21 @@ 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)? @@ -132,5 +147,5 @@ There may be more modes. tridentfb - Trident (Cyber)blade chipset frame buffer vt8623fb - VIA 8623 frame buffer -BTW, only a few drivers use this at the moment. Others are to follow -(feel free to send patches). +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. diff --git a/Documentation/fb/pxafb.txt b/Documentation/fb/pxafb.txt index db9b8500b43..d143a0a749f 100644 --- a/Documentation/fb/pxafb.txt +++ b/Documentation/fb/pxafb.txt @@ -5,9 +5,13 @@ The driver supports the following options, either via options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in. For example: - modprobe pxafb options=mode:640x480-8,passive + modprobe pxafb options=vmem:2M,mode:640x480-8,passive or on the kernel command line - video=pxafb:mode:640x480-8,passive + video=pxafb:vmem:2M,mode:640x480-8,passive + +vmem: VIDEO_MEM_SIZE + Amount of video memory to allocate (can be suffixed with K or M + for kilobytes or megabytes) mode:XRESxYRES[-BPP] XRES == LCCR1_PPL + 1 @@ -52,3 +56,87 @@ outputen:POLARITY pixclockpol:POLARITY pixel clock polarity 0 => falling edge, 1 => rising edge + + +Overlay Support for PXA27x and later LCD controllers +==================================================== + + PXA27x and later processors support overlay1 and overlay2 on-top of the + base framebuffer (although under-neath the base is also possible). They + support palette and no-palette RGB formats, as well as YUV formats (only + available on overlay2). These overlays have dedicated DMA channels and + behave in a similar way as a framebuffer. + + However, there are some differences between these overlay framebuffers + and normal framebuffers, as listed below: + + 1. overlay can start at a 32-bit word aligned position within the base + framebuffer, which means they have a start (x, y). This information + is encoded into var->nonstd (no, var->xoffset and var->yoffset are + not for such purpose). + + 2. overlay framebuffer is allocated dynamically according to specified + 'struct fb_var_screeninfo', the amount is decided by: + + var->xres_virtual * var->yres_virtual * bpp + + bpp = 16 -- for RGB565 or RGBT555 + = 24 -- for YUV444 packed + = 24 -- for YUV444 planar + = 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr) + = 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr) + + NOTE: + + a. overlay does not support panning in x-direction, thus + var->xres_virtual will always be equal to var->xres + + b. line length of overlay(s) must be on a 32-bit word boundary, + for YUV planar modes, it is a requirement for the component + with minimum bits per pixel, e.g. for YUV420, Cr component + for one pixel is actually 2-bits, it means the line length + should be a multiple of 16-pixels + + c. starting horizontal position (XPOS) should start on a 32-bit + word boundary, otherwise the fb_check_var() will just fail. + + d. the rectangle of the overlay should be within the base plane, + otherwise fail + + Applications should follow the sequence below to operate an overlay + framebuffer: + + a. open("/dev/fb[1-2]", ...) + b. ioctl(fd, FBIOGET_VSCREENINFO, ...) + c. modify 'var' with desired parameters: + 1) var->xres and var->yres + 2) larger var->yres_virtual if more memory is required, + usually for double-buffering + 3) var->nonstd for starting (x, y) and color format + 4) var->{red, green, blue, transp} if RGB mode is to be used + d. ioctl(fd, FBIOPUT_VSCREENINFO, ...) + e. ioctl(fd, FBIOGET_FSCREENINFO, ...) + f. mmap + g. ... + + 3. for YUV planar formats, these are actually not supported within the + framebuffer framework, application has to take care of the offsets + and lengths of each component within the framebuffer. + + 4. var->nonstd is used to pass starting (x, y) position and color format, + the detailed bit fields are shown below: + + 31 23 20 10 0 + +-----------------+---+----------+----------+ + | ... unused ... |FOR| XPOS | YPOS | + +-----------------+---+----------+----------+ + + FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h + 0 - RGB + 1 - YUV444 PACKED + 2 - YUV444 PLANAR + 3 - YUV422 PLANAR + 4 - YUR420 PLANAR + + XPOS - starting horizontal position + YPOS - starting vertical position diff --git a/Documentation/fb/sh7760fb.txt b/Documentation/fb/sh7760fb.txt index c87bfe5c630..b994c3b1054 100644 --- a/Documentation/fb/sh7760fb.txt +++ b/Documentation/fb/sh7760fb.txt @@ -1,7 +1,7 @@ SH7760/SH7763 integrated LCDC Framebuffer driver ================================================ -0. Overwiew +0. Overview ----------- The SH7760/SH7763 have an integrated LCD Display controller (LCDC) which supports (in theory) resolutions ranging from 1x1 to 1024x1024, diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt new file mode 100644 index 00000000000..187f3b3ccb6 --- /dev/null +++ b/Documentation/fb/sm501.txt @@ -0,0 +1,10 @@ +Configuration: + +You can pass the following kernel command line options to sm501 videoframebuffer: + + sm501fb.bpp= SM501 Display driver: + Specify bits-per-pixel if not specified by 'mode' + + sm501fb.mode= SM501 Display driver: + Specify resolution as + "<xres>x<yres>[-<bpp>][@<refresh>]" diff --git a/Documentation/fb/sstfb.txt b/Documentation/fb/sstfb.txt index 550ca775a4c..13db1075e4a 100644 --- a/Documentation/fb/sstfb.txt +++ b/Documentation/fb/sstfb.txt @@ -10,7 +10,7 @@ Introduction The main page is located at <http://sstfb.sourceforge.net>, and if you want the latest version, check out the CVS, as the driver is a work in progress, I feel uncomfortable with releasing tarballs of something - not completely working...Don't worry, it's still more than useable + not completely working...Don't worry, it's still more than usable (I eat my own dog food) Please read the Bug section, and report any success or failure to me diff --git a/Documentation/fb/udlfb.txt b/Documentation/fb/udlfb.txt new file mode 100644 index 00000000000..57d2f2908b1 --- /dev/null +++ b/Documentation/fb/udlfb.txt @@ -0,0 +1,159 @@ + +What is udlfb? +=============== + +This is a driver for DisplayLink USB 2.0 era graphics chips. + +DisplayLink chips provide simple hline/blit operations with some compression, +pairing that with a hardware framebuffer (16MB) on the other end of the +USB wire. That hardware framebuffer is able to drive the VGA, DVI, or HDMI +monitor with no CPU involvement until a pixel has to change. + +The CPU or other local resource does all the rendering; optinally compares the +result with a local shadow of the remote hardware framebuffer to identify +the minimal set of pixels that have changed; and compresses and sends those +pixels line-by-line via USB bulk transfers. + +Because of the efficiency of bulk transfers and a protocol on top that +does not require any acks - the effect is very low latency that +can support surprisingly high resolutions with good performance for +non-gaming and non-video applications. + +Mode setting, EDID read, etc are other bulk or control transfers. Mode +setting is very flexible - able to set nearly arbitrary modes from any timing. + +Advantages of USB graphics in general: + + * Ability to add a nearly arbitrary number of displays to any USB 2.0 + capable system. On Linux, number of displays is limited by fbdev interface + (FB_MAX is currently 32). Of course, all USB devices on the same + host controller share the same 480Mbs USB 2.0 interface. + +Advantages of supporting DisplayLink chips with kernel framebuffer interface: + + * The actual hardware functionality of DisplayLink chips matches nearly + one-to-one with the fbdev interface, making the driver quite small and + tight relative to the functionality it provides. + * X servers and other applications can use the standard fbdev interface + from user mode to talk to the device, without needing to know anything + about USB or DisplayLink's protocol at all. A "displaylink" X driver + and a slightly modified "fbdev" X driver are among those that already do. + +Disadvantages: + + * Fbdev's mmap interface assumes a real hardware framebuffer is mapped. + In the case of USB graphics, it is just an allocated (virtual) buffer. + Writes need to be detected and encoded into USB bulk transfers by the CPU. + Accurate damage/changed area notifications work around this problem. + In the future, hopefully fbdev will be enhanced with an small standard + interface to allow mmap clients to report damage, for the benefit + of virtual or remote framebuffers. + * Fbdev does not arbitrate client ownership of the framebuffer well. + * Fbcon assumes the first framebuffer it finds should be consumed for console. + * It's not clear what the future of fbdev is, given the rise of KMS/DRM. + +How to use it? +============== + +Udlfb, when loaded as a module, will match against all USB 2.0 generation +DisplayLink chips (Alex and Ollie family). It will then attempt to read the EDID +of the monitor, and set the best common mode between the DisplayLink device +and the monitor's capabilities. + +If the DisplayLink device is successful, it will paint a "green screen" which +means that from a hardware and fbdev software perspective, everything is good. + +At that point, a /dev/fb? interface will be present for user-mode applications +to open and begin writing to the framebuffer of the DisplayLink device using +standard fbdev calls. Note that if mmap() is used, by default the user mode +application must send down damage notifcations to trigger repaints of the +changed regions. Alternatively, udlfb can be recompiled with experimental +defio support enabled, to support a page-fault based detection mechanism +that can work without explicit notifcation. + +The most common client of udlfb is xf86-video-displaylink or a modified +xf86-video-fbdev X server. These servers have no real DisplayLink specific +code. They write to the standard framebuffer interface and rely on udlfb +to do its thing. The one extra feature they have is the ability to report +rectangles from the X DAMAGE protocol extension down to udlfb via udlfb's +damage interface (which will hopefully be standardized for all virtual +framebuffers that need damage info). These damage notifications allow +udlfb to efficiently process the changed pixels. + +Module Options +============== + +Special configuration for udlfb is usually unnecessary. There are a few +options, however. + +From the command line, pass options to modprobe +modprobe udlfb fb_defio=0 console=1 shadow=1 + +Or modify options on the fly at /sys/module/udlfb/parameters directory via +sudo nano fb_defio +change the parameter in place, and save the file. + +Unplug/replug USB device to apply with new settings + +Or for permanent option, create file like /etc/modprobe.d/udlfb.conf with text +options udlfb fb_defio=0 console=1 shadow=1 + +Accepted boolean options: + +fb_defio Make use of the fb_defio (CONFIG_FB_DEFERRED_IO) kernel + module to track changed areas of the framebuffer by page faults. + Standard fbdev applications that use mmap but that do not + report damage, should be able to work with this enabled. + Disable when running with X server that supports reporting + changed regions via ioctl, as this method is simpler, + more stable, and higher performance. + default: fb_defio=1 + +console Allow fbcon to attach to udlfb provided framebuffers. + Can be disabled if fbcon and other clients + (e.g. X with --shared-vt) are in conflict. + default: console=1 + +shadow Allocate a 2nd framebuffer to shadow what's currently across + the USB bus in device memory. If any pixels are unchanged, + do not transmit. Spends host memory to save USB transfers. + Enabled by default. Only disable on very low memory systems. + default: shadow=1 + +Sysfs Attributes +================ + +Udlfb creates several files in /sys/class/graphics/fb? +Where ? is the sequential framebuffer id of the particular DisplayLink device + +edid If a valid EDID blob is written to this file (typically + by a udev rule), then udlfb will use this EDID as a + backup in case reading the actual EDID of the monitor + attached to the DisplayLink device fails. This is + especially useful for fixed panels, etc. that cannot + communicate their capabilities via EDID. Reading + this file returns the current EDID of the attached + monitor (or last backup value written). This is + useful to get the EDID of the attached monitor, + which can be passed to utilities like parse-edid. + +metrics_bytes_rendered 32-bit count of pixel bytes rendered + +metrics_bytes_identical 32-bit count of how many of those bytes were found to be + unchanged, based on a shadow framebuffer check + +metrics_bytes_sent 32-bit count of how many bytes were transferred over + USB to communicate the resulting changed pixels to the + hardware. Includes compression and protocol overhead + +metrics_cpu_kcycles_used 32-bit count of CPU cycles used in processing the + above pixels (in thousands of cycles). + +metrics_reset Write-only. Any write to this file resets all metrics + above to zero. Note that the 32-bit counters above + roll over very quickly. To get reliable results, design + performance tests to start and finish in a very short + period of time (one minute or less is safe). + +-- +Bernie Thompson <bernie@plugable.com> diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt index bcfc233a008..f6362d88763 100644 --- a/Documentation/fb/uvesafb.txt +++ b/Documentation/fb/uvesafb.txt @@ -52,14 +52,15 @@ are either given on the kernel command line or as module parameters, e.g.: video=uvesafb:1024x768-32,mtrr:3,ywrap (compiled into the kernel) - # modprobe uvesafb mode=1024x768-32 mtrr=3 scroll=ywrap (module) + # modprobe uvesafb mode_option=1024x768-32 mtrr=3 scroll=ywrap (module) Accepted options: ypan Enable display panning using the VESA protected mode interface. The visible screen is just a window of the video memory, console scrolling is done by changing the - start of the window. Available on x86 only. + start of the window. This option is available on x86 + only and is the default option on that architecture. ywrap Same as ypan, but assumes your gfx board can wrap-around the video memory (i.e. starts reading from top if it @@ -67,7 +68,7 @@ ywrap Same as ypan, but assumes your gfx board can wrap-around Available on x86 only. redraw Scroll by redrawing the affected part of the screen, this - is the safe (and slow) default. + is the default on non-x86. (If you're using uvesafb as a module, the above three options are used a parameter of the scroll option, e.g. scroll=ypan.) @@ -80,17 +81,11 @@ pmipal Use the protected mode interface for palette changes. mtrr:n Setup memory type range registers for the framebuffer where n: - 0 - disabled (equivalent to nomtrr) (default) - 1 - uncachable - 2 - write-back - 3 - write-combining - 4 - write-through - - If you see the following in dmesg, choose the type that matches - the old one. In this example, use "mtrr:2". -... -mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining -... + 0 - disabled (equivalent to nomtrr) + 3 - write-combining (default) + + Values other than 0 and 3 will result in a warning and will be + treated just like 3. nomtrr Do not use memory type range registers. @@ -105,7 +100,7 @@ vtotal:n <mode> The mode you want to set, in the standard modedb format. Refer to modedb.txt for a detailed description. When uvesafb is compiled as a module, the mode string should be provided as a value of the - 'mode' option. + 'mode_option' option. vbemode:x Force the use of VBE mode x. The mode will only be set if it's @@ -182,7 +177,7 @@ from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo. -- Michal Januszewski <spock@gentoo.org> - Last updated: 2007-06-16 + Last updated: 2009-03-30 Documentation of the uvesafb options is loosely based on vesafb.txt. diff --git a/Documentation/fb/vesafb.txt b/Documentation/fb/vesafb.txt index ee277dd204b..950d5a658cb 100644 --- a/Documentation/fb/vesafb.txt +++ b/Documentation/fb/vesafb.txt @@ -95,7 +95,7 @@ There is no way to change the vesafb video mode and/or timings after booting linux. If you are not happy with the 60 Hz refresh rate, you have these options: - * configure and load the DOS-Tools for your the graphics board (if + * configure and load the DOS-Tools for the graphics board (if available) and boot linux with loadlin. * use a native driver (matroxfb/atyfb) instead if vesafb. If none is available, write a new one! diff --git a/Documentation/fb/viafb.modes b/Documentation/fb/viafb.modes new file mode 100644 index 00000000000..2a547da2e5c --- /dev/null +++ b/Documentation/fb/viafb.modes @@ -0,0 +1,870 @@ +# +# +# These data are based on the CRTC parameters in +# +# VIA Integration Graphics Chip +# (C) 2004 VIA Technologies Inc. +# + +# +# 640x480, 60 Hz, Non-Interlaced (25.175 MHz dotclock) +# +# Horizontal Vertical +# Resolution 640 480 +# Scan Frequency 31.469 kHz 59.94 Hz +# Sync Width 3.813 us 0.064 ms +# 12 chars 2 lines +# Front Porch 0.636 us 0.318 ms +# 2 chars 10 lines +# Back Porch 1.907 us 1.048 ms +# 6 chars 33 lines +# Active Time 25.422 us 15.253 ms +# 80 chars 480 lines +# Blank Time 6.356 us 1.430 ms +# 20 chars 45 lines +# Polarity negative negative +# + +mode "640x480-60" +# D: 25.175 MHz, H: 31.469 kHz, V: 59.94 Hz + geometry 640 480 640 480 32 + timings 39722 48 16 33 10 96 2 endmode mode "480x640-60" +# D: 24.823 MHz, H: 39.780 kHz, V: 60.00 Hz + geometry 480 640 480 640 32 timings 39722 72 24 19 1 48 3 endmode +# +# 640x480, 75 Hz, Non-Interlaced (31.50 MHz dotclock) +# +# Horizontal Vertical +# Resolution 640 480 +# Scan Frequency 37.500 kHz 75.00 Hz +# Sync Width 2.032 us 0.080 ms +# 8 chars 3 lines +# Front Porch 0.508 us 0.027 ms +# 2 chars 1 lines +# Back Porch 3.810 us 0.427 ms +# 15 chars 16 lines +# Active Time 20.317 us 12.800 ms +# 80 chars 480 lines +# Blank Time 6.349 us 0.533 ms +# 25 chars 20 lines +# Polarity negative negative +# + mode "640x480-75" +# D: 31.50 MHz, H: 37.500 kHz, V: 75.00 Hz + geometry 640 480 640 480 32 timings 31747 120 16 16 1 64 3 endmode +# +# 640x480, 85 Hz, Non-Interlaced (36.000 MHz dotclock) +# +# Horizontal Vertical +# Resolution 640 480 +# Scan Frequency 43.269 kHz 85.00 Hz +# Sync Width 1.556 us 0.069 ms +# 7 chars 3 lines +# Front Porch 1.556 us 0.023 ms +# 7 chars 1 lines +# Back Porch 2.222 us 0.578 ms +# 10 chars 25 lines +# Active Time 17.778 us 11.093 ms +# 80 chars 480 lines +# Blank Time 5.333 us 0.670 ms +# 24 chars 29 lines +# Polarity negative negative +# + mode "640x480-85" +# D: 36.000 MHz, H: 43.269 kHz, V: 85.00 Hz + geometry 640 480 640 480 32 timings 27777 80 56 25 1 56 3 endmode +# +# 640x480, 100 Hz, Non-Interlaced (43.163 MHz dotclock) +# +# Horizontal Vertical +# Resolution 640 480 +# Scan Frequency 50.900 kHz 100.00 Hz +# Sync Width 1.483 us 0.058 ms +# 8 chars 3 lines +# Front Porch 0.927 us 0.019 ms +# 5 chars 1 lines +# Back Porch 2.409 us 0.475 ms +# 13 chars 25 lines +# Active Time 14.827 us 9.430 ms +# 80 chars 480 lines +# Blank Time 4.819 us 0.570 ms +# 26 chars 29 lines +# Polarity positive positive +# + mode "640x480-100" +# D: 43.163 MHz, H: 50.900 kHz, V: 100.00 Hz + geometry 640 480 640 480 32 timings 23168 104 40 25 1 64 3 endmode +# +# 640x480, 120 Hz, Non-Interlaced (52.406 MHz dotclock) +# +# Horizontal Vertical +# Resolution 640 480 +# Scan Frequency 61.800 kHz 120.00 Hz +# Sync Width 1.221 us 0.048 ms +# 8 chars 3 lines +# Front Porch 0.763 us 0.016 ms +# 5 chars 1 lines +# Back Porch 1.984 us 0.496 ms +# 13 chars 31 lines +# Active Time 12.212 us 7.767 ms +# 80 chars 480 lines +# Blank Time 3.969 us 0.566 ms +# 26 chars 35 lines +# Polarity positive positive +# + mode "640x480-120" +# D: 52.406 MHz, H: 61.800 kHz, V: 120.00 Hz + geometry 640 480 640 480 32 timings 19081 104 40 31 1 64 3 endmode +# +# 720x480, 60 Hz, Non-Interlaced (26.880 MHz dotclock) +# +# Horizontal Vertical +# Resolution 720 480 +# Scan Frequency 30.000 kHz 60.241 Hz +# Sync Width 2.679 us 0.099 ms +# 9 chars 3 lines +# Front Porch 0.595 us 0.033 ms +# 2 chars 1 lines +# Back Porch 3.274 us 0.462 ms +# 11 chars 14 lines +# Active Time 26.786 us 16.000 ms +# 90 chars 480 lines +# Blank Time 6.548 us 0.600 ms +# 22 chars 18 lines +# Polarity positive positive +# + mode "720x480-60" +# D: 26.880 MHz, H: 30.000 kHz, V: 60.24 Hz + geometry 720 480 720 480 32 timings 37202 88 16 14 1 72 3 endmode +# +# 800x480, 60 Hz, Non-Interlaced (29.581 MHz dotclock) +# +# Horizontal Vertical +# Resolution 800 480 +# Scan Frequency 29.892 kHz 60.00 Hz +# Sync Width 2.704 us 100.604 us +# 10 chars 3 lines +# Front Porch 0.541 us 33.535 us +# 2 chars 1 lines +# Back Porch 3.245 us 435.949 us +# 12 chars 13 lines +# Active Time 27.044 us 16.097 ms +# 100 chars 480 lines +# Blank Time 6.491 us 0.570 ms +# 24 chars 17 lines +# Polarity positive positive +# + mode "800x480-60" +# D: 29.500 MHz, H: 29.738 kHz, V: 60.00 Hz + geometry 800 480 800 480 32 timings 33805 96 24 10 3 72 7 endmode +# +# 720x576, 60 Hz, Non-Interlaced (32.668 MHz dotclock) +# +# Horizontal Vertical +# Resolution 720 576 +# Scan Frequency 35.820 kHz 60.00 Hz +# Sync Width 2.204 us 0.083 ms +# 9 chars 3 lines +# Front Porch 0.735 us 0.027 ms +# 3 chars 1 lines +# Back Porch 2.939 us 0.459 ms +# 12 chars 17 lines +# Active Time 22.040 us 16.080 ms +# 90 chars 476 lines +# Blank Time 5.877 us 0.586 ms +# 24 chars 21 lines +# Polarity positive positive +# + mode "720x576-60" +# D: 32.668 MHz, H: 35.820 kHz, V: 60.00 Hz + geometry 720 576 720 576 32 timings 30611 96 24 17 1 72 3 endmode +# +# 800x600, 60 Hz, Non-Interlaced (40.00 MHz dotclock) +# +# Horizontal Vertical +# Resolution 800 600 +# Scan Frequency 37.879 kHz 60.32 Hz +# Sync Width 3.200 us 0.106 ms +# 16 chars 4 lines +# Front Porch 1.000 us 0.026 ms +# 5 chars 1 lines +# Back Porch 2.200 us 0.607 ms +# 11 chars 23 lines +# Active Time 20.000 us 15.840 ms +# 100 chars 600 lines +# Blank Time 6.400 us 0.739 ms +# 32 chars 28 lines +# Polarity positive positive +# + mode "800x600-60" +# D: 40.00 MHz, H: 37.879 kHz, V: 60.32 Hz + geometry 800 600 800 600 32 + timings 25000 88 40 23 1 128 4 hsync high vsync high endmode +# +# 800x600, 75 Hz, Non-Interlaced (49.50 MHz dotclock) +# +# Horizontal Vertical +# Resolution 800 600 +# Scan Frequency 46.875 kHz 75.00 Hz +# Sync Width 1.616 us 0.064 ms +# 10 chars 3 lines +# Front Porch 0.323 us 0.021 ms +# 2 chars 1 lines +# Back Porch 3.232 us 0.448 ms +# 20 chars 21 lines +# Active Time 16.162 us 12.800 ms +# 100 chars 600 lines +# Blank Time 5.172 us 0.533 ms +# 32 chars 25 lines +# Polarity positive positive +# + mode "800x600-75" +# D: 49.50 MHz, H: 46.875 kHz, V: 75.00 Hz + geometry 800 600 800 600 32 + timings 20203 160 16 21 1 80 3 hsync high vsync high endmode +# +# 800x600, 85 Hz, Non-Interlaced (56.25 MHz dotclock) +# +# Horizontal Vertical +# Resolution 800 600 +# Scan Frequency 53.674 kHz 85.061 Hz +# Sync Width 1.138 us 0.056 ms +# 8 chars 3 lines +# Front Porch 0.569 us 0.019 ms +# 4 chars 1 lines +# Back Porch 2.702 us 0.503 ms +# 19 chars 27 lines +# Active Time 14.222 us 11.179 ms +# 100 chars 600 lines +# Blank Time 4.409 us 0.578 ms +# 31 chars 31 lines +# Polarity positive positive +# + mode "800x600-85" +# D: 56.25 MHz, H: 53.674 kHz, V: 85.061 Hz + geometry 800 600 800 600 32 + timings 17777 152 32 27 1 64 3 hsync high vsync high endmode +# +# 800x600, 100 Hz, Non-Interlaced (67.50 MHz dotclock) +# +# Horizontal Vertical +# Resolution 800 600 +# Scan Frequency 62.500 kHz 100.00 Hz +# Sync Width 0.948 us 0.064 ms +# 8 chars 4 lines +# Front Porch 0.000 us 0.112 ms +# 0 chars 7 lines +# Back Porch 3.200 us 0.224 ms +# 27 chars 14 lines +# Active Time 11.852 us 9.600 ms +# 100 chars 600 lines +# Blank Time 4.148 us 0.400 ms +# 35 chars 25 lines +# Polarity positive positive +# + mode "800x600-100" +# D: 67.50 MHz, H: 62.500 kHz, V: 100.00 Hz + geometry 800 600 800 600 32 + timings 14667 216 0 14 7 64 4 hsync high vsync high endmode +# +# 800x600, 120 Hz, Non-Interlaced (83.950 MHz dotclock) +# +# Horizontal Vertical +# Resolution 800 600 +# Scan Frequency 77.160 kHz 120.00 Hz +# Sync Width 1.048 us 0.039 ms +# 11 chars 3 lines +# Front Porch 0.667 us 0.013 ms +# 7 chars 1 lines +# Back Porch 1.715 us 0.507 ms +# 18 chars 39 lines +# Active Time 9.529 us 7.776 ms +# 100 chars 600 lines +# Blank Time 3.431 us 0.557 ms +# 36 chars 43 lines +# Polarity positive positive +# + mode "800x600-120" +# D: 83.950 MHz, H: 77.160 kHz, V: 120.00 Hz + geometry 800 600 800 600 32 + timings 11912 144 56 39 1 88 3 hsync high vsync high endmode +# +# 848x480, 60 Hz, Non-Interlaced (31.490 MHz dotclock) +# +# Horizontal Vertical +# Resolution 848 480 +# Scan Frequency 29.820 kHz 60.00 Hz +# Sync Width 2.795 us 0.099 ms +# 11 chars 3 lines +# Front Porch 0.508 us 0.033 ms +# 2 chars 1 lines +# Back Porch 3.303 us 0.429 ms +# 13 chars 13 lines +# Active Time 26.929 us 16.097 ms +# 106 chars 480 lines +# Blank Time 6.605 us 0.570 ms +# 26 chars 17 lines +# Polarity positive positive +# + mode "848x480-60" +# D: 31.500 MHz, H: 29.830 kHz, V: 60.00 Hz + geometry 848 480 848 480 32 + timings 31746 104 24 12 3 80 5 hsync high vsync high endmode +# +# 856x480, 60 Hz, Non-Interlaced (31.728 MHz dotclock) +# +# Horizontal Vertical +# Resolution 856 480 +# Scan Frequency 29.820 kHz 60.00 Hz +# Sync Width 2.774 us 0.099 ms +# 11 chars 3 lines +# Front Porch 0.504 us 0.033 ms +# 2 chars 1 lines +# Back Porch 3.728 us 0.429 ms +# 13 chars 13 lines +# Active Time 26.979 us 16.097 ms +# 107 chars 480 lines +# Blank Time 6.556 us 0.570 ms +# 26 chars 17 lines +# Polarity positive positive +# + mode "856x480-60" +# D: 31.728 MHz, H: 29.820 kHz, V: 60.00 Hz + geometry 856 480 856 480 32 + timings 31518 104 16 13 1 88 3 + hsync high vsync high endmode mode "960x600-60" +# D: 45.250 MHz, H: 37.212 kHz, V: 60.00 Hz + geometry 960 600 960 600 32 timings 22099 128 32 15 3 96 6 endmode +# +# 1000x600, 60 Hz, Non-Interlaced (48.068 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1000 600 +# Scan Frequency 37.320 kHz 60.00 Hz +# Sync Width 2.164 us 0.080 ms +# 13 chars 3 lines +# Front Porch 0.832 us 0.027 ms +# 5 chars 1 lines +# Back Porch 2.996 us 0.483 ms +# 18 chars 18 lines +# Active Time 20.804 us 16.077 ms +# 125 chars 600 lines +# Blank Time 5.991 us 0.589 ms +# 36 chars 22 lines +# Polarity negative positive +# + mode "1000x600-60" +# D: 48.068 MHz, H: 37.320 kHz, V: 60.00 Hz + geometry 1000 600 1000 600 32 + timings 20834 144 40 18 1 104 3 endmode mode "1024x576-60" +# D: 46.996 MHz, H: 35.820 kHz, V: 60.00 Hz + geometry 1024 576 1024 576 32 + timings 21278 144 40 17 1 104 3 endmode mode "1024x600-60" +# D: 48.964 MHz, H: 37.320 kHz, V: 60.00 Hz + geometry 1024 600 1024 600 32 + timings 20461 144 40 18 1 104 3 endmode mode "1088x612-60" +# D: 52.952 MHz, H: 38.040 kHz, V: 60.00 Hz + geometry 1088 612 1088 612 32 timings 18877 152 48 16 3 104 5 endmode +# +# 1024x512, 60 Hz, Non-Interlaced (41.291 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1024 512 +# Scan Frequency 31.860 kHz 60.00 Hz +# Sync Width 2.519 us 0.094 ms +# 13 chars 3 lines +# Front Porch 0.775 us 0.031 ms +# 4 chars 1 lines +# Back Porch 3.294 us 0.465 ms +# 17 chars 15 lines +# Active Time 24.800 us 16.070 ms +# 128 chars 512 lines +# Blank Time 6.587 us 0.596 ms +# 34 chars 19 lines +# Polarity positive positive +# + mode "1024x512-60" +# D: 41.291 MHz, H: 31.860 kHz, V: 60.00 Hz + geometry 1024 512 1024 512 32 + timings 24218 126 32 15 1 104 3 hsync high vsync high endmode +# +# 1024x600, 60 Hz, Non-Interlaced (48.875 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1024 768 +# Scan Frequency 37.252 kHz 60.00 Hz +# Sync Width 2.128 us 80.532us +# 13 chars 3 lines +# Front Porch 0.818 us 26.844 us +# 5 chars 1 lines +# Back Porch 2.946 us 483.192 us +# 18 chars 18 lines +# Active Time 20.951 us 16.697 ms +# 128 chars 622 lines +# Blank Time 5.893 us 0.591 ms +# 36 chars 22 lines +# Polarity negative positive +# +#mode "1024x600-60" +# # D: 48.875 MHz, H: 37.252 kHz, V: 60.00 Hz +# geometry 1024 600 1024 600 32 +# timings 20460 144 40 18 1 104 3 +# endmode +# +# 1024x768, 60 Hz, Non-Interlaced (65.00 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1024 768 +# Scan Frequency 48.363 kHz 60.00 Hz +# Sync Width 2.092 us 0.124 ms +# 17 chars 6 lines +# Front Porch 0.369 us 0.062 ms +# 3 chars 3 lines +# Back Porch 2.462 us 0.601 ms +# 20 chars 29 lines +# Active Time 15.754 us 15.880 ms +# 128 chars 768 lines +# Blank Time 4.923 us 0.786 ms +# 40 chars 38 lines +# Polarity negative negative +# + mode "1024x768-60" +# D: 65.00 MHz, H: 48.363 kHz, V: 60.00 Hz + geometry 1024 768 1024 768 32 timings 15385 160 24 29 3 136 6 endmode +# +# 1024x768, 75 Hz, Non-Interlaced (78.75 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1024 768 +# Scan Frequency 60.023 kHz 75.03 Hz +# Sync Width 1.219 us 0.050 ms +# 12 chars 3 lines +# Front Porch 0.203 us 0.017 ms +# 2 chars 1 lines +# Back Porch 2.235 us 0.466 ms +# 22 chars 28 lines +# Active Time 13.003 us 12.795 ms +# 128 chars 768 lines +# Blank Time 3.657 us 0.533 ms +# 36 chars 32 lines +# Polarity positive positive +# + mode "1024x768-75" +# D: 78.75 MHz, H: 60.023 kHz, V: 75.03 Hz + geometry 1024 768 1024 768 32 + timings 12699 176 16 28 1 96 3 hsync high vsync high endmode +# +# 1024x768, 85 Hz, Non-Interlaced (94.50 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1024 768 +# Scan Frequency 68.677 kHz 85.00 Hz +# Sync Width 1.016 us 0.044 ms +# 12 chars 3 lines +# Front Porch 0.508 us 0.015 ms +# 6 chars 1 lines +# Back Porch 2.201 us 0.524 ms +# 26 chars 36 lines +# Active Time 10.836 us 11.183 ms +# 128 chars 768 lines +# Blank Time 3.725 us 0.582 ms +# 44 chars 40 lines +# Polarity positive positive +# + mode "1024x768-85" +# D: 94.50 MHz, H: 68.677 kHz, V: 85.00 Hz + geometry 1024 768 1024 768 32 + timings 10582 208 48 36 1 96 3 hsync high vsync high endmode +# +# 1024x768, 100 Hz, Non-Interlaced (110.0 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1024 768 +# Scan Frequency 79.023 kHz 99.78 Hz +# Sync Width 0.800 us 0.101 ms +# 11 chars 8 lines +# Front Porch 0.000 us 0.000 ms +# 0 chars 0 lines +# Back Porch 2.545 us 0.202 ms +# 35 chars 16 lines +# Active Time 9.309 us 9.719 ms +# 128 chars 768 lines +# Blank Time 3.345 us 0.304 ms +# 46 chars 24 lines +# Polarity negative negative +# + mode "1024x768-100" +# D: 113.3 MHz, H: 79.023 kHz, V: 99.78 Hz + geometry 1024 768 1024 768 32 + timings 8825 280 0 16 0 88 8 endmode mode "1152x720-60" +# D: 66.750 MHz, H: 44.859 kHz, V: 60.00 Hz + geometry 1152 720 1152 720 32 timings 14981 168 56 19 3 112 6 endmode +# +# 1152x864, 75 Hz, Non-Interlaced (110.0 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1152 864 +# Scan Frequency 75.137 kHz 74.99 Hz +# Sync Width 1.309 us 0.106 ms +# 18 chars 8 lines +# Front Porch 0.245 us 0.599 ms +# 3 chars 45 lines +# Back Porch 1.282 us 1.132 ms +# 18 chars 85 lines +# Active Time 10.473 us 11.499 ms +# 144 chars 864 lines +# Blank Time 2.836 us 1.837 ms +# 39 chars 138 lines +# Polarity positive positive +# + mode "1152x864-75" +# D: 110.0 MHz, H: 75.137 kHz, V: 74.99 Hz + geometry 1152 864 1152 864 32 + timings 9259 144 24 85 45 144 8 + hsync high vsync high endmode mode "1200x720-60" +# D: 70.184 MHz, H: 44.760 kHz, V: 60.00 Hz + geometry 1200 720 1200 720 32 + timings 14253 184 28 22 1 128 3 endmode mode "1280x600-60" +# D: 61.503 MHz, H: 37.320 kHz, V: 60.00 Hz + geometry 1280 600 1280 600 32 + timings 16260 184 28 18 1 128 3 endmode mode "1280x720-50" +# D: 60.466 MHz, H: 37.050 kHz, V: 50.00 Hz + geometry 1280 720 1280 720 32 + timings 16538 176 48 17 1 128 3 endmode mode "1280x768-50" +# D: 65.178 MHz, H: 39.550 kHz, V: 50.00 Hz + geometry 1280 768 1280 768 32 timings 15342 184 28 19 1 128 3 endmode +# +# 1280x768, 60 Hz, Non-Interlaced (80.136 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 768 +# Scan Frequency 47.700 kHz 60.00 Hz +# Sync Width 1.697 us 0.063 ms +# 17 chars 3 lines +# Front Porch 0.799 us 0.021 ms +# 8 chars 1 lines +# Back Porch 2.496 us 0.483 ms +# 25 chars 23 lines +# Active Time 15.973 us 16.101 ms +# 160 chars 768 lines +# Blank Time 4.992 us 0.566 ms +# 50 chars 27 lines +# Polarity positive positive +# + mode "1280x768-60" +# D: 80.13 MHz, H: 47.700 kHz, V: 60.00 Hz + geometry 1280 768 1280 768 32 + timings 12480 200 48 23 1 126 3 hsync high vsync high endmode +# +# 1280x800, 60 Hz, Non-Interlaced (83.375 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 800 +# Scan Frequency 49.628 kHz 60.00 Hz +# Sync Width 1.631 us 60.450 us +# 17 chars 3 lines +# Front Porch 0.768 us 20.15 us +# 8 chars 1 lines +# Back Porch 2.399 us 0.483 ms +# 25 chars 24 lines +# Active Time 15.352 us 16.120 ms +# 160 chars 800 lines +# Blank Time 4.798 us 0.564 ms +# 50 chars 28 lines +# Polarity negative positive +# + mode "1280x800-60" +# D: 83.500 MHz, H: 49.702 kHz, V: 60.00 Hz + geometry 1280 800 1280 800 32 timings 11994 200 72 22 3 128 6 endmode +# +# 1280x960, 60 Hz, Non-Interlaced (108.00 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 960 +# Scan Frequency 60.000 kHz 60.00 Hz +# Sync Width 1.037 us 0.050 ms +# 14 chars 3 lines +# Front Porch 0.889 us 0.017 ms +# 12 chars 1 lines +# Back Porch 2.889 us 0.600 ms +# 39 chars 36 lines +# Active Time 11.852 us 16.000 ms +# 160 chars 960 lines +# Blank Time 4.815 us 0.667 ms +# 65 chars 40 lines +# Polarity positive positive +# + mode "1280x960-60" +# D: 108.00 MHz, H: 60.000 kHz, V: 60.00 Hz + geometry 1280 960 1280 960 32 + timings 9259 312 96 36 1 112 3 hsync high vsync high endmode +# +# 1280x1024, 60 Hz, Non-Interlaced (108.00 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 1024 +# Scan Frequency 63.981 kHz 60.02 Hz +# Sync Width 1.037 us 0.047 ms +# 14 chars 3 lines +# Front Porch 0.444 us 0.015 ms +# 6 chars 1 lines +# Back Porch 2.297 us 0.594 ms +# 31 chars 38 lines +# Active Time 11.852 us 16.005 ms +# 160 chars 1024 lines +# Blank Time 3.778 us 0.656 ms +# 51 chars 42 lines +# Polarity positive positive +# + mode "1280x1024-60" +# D: 108.00 MHz, H: 63.981 kHz, V: 60.02 Hz + geometry 1280 1024 1280 1024 32 + timings 9260 248 48 38 1 112 3 hsync high vsync high endmode +# +# 1280x1024, 75 Hz, Non-Interlaced (135.00 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 1024 +# Scan Frequency 79.976 kHz 75.02 Hz +# Sync Width 1.067 us 0.038 ms +# 18 chars 3 lines +# Front Porch 0.119 us 0.012 ms +# 2 chars 1 lines +# Back Porch 1.837 us 0.475 ms +# 31 chars 38 lines +# Active Time 9.481 us 12.804 ms +# 160 chars 1024 lines +# Blank Time 3.022 us 0.525 ms +# 51 chars 42 lines +# Polarity positive positive +# + mode "1280x1024-75" +# D: 135.00 MHz, H: 79.976 kHz, V: 75.02 Hz + geometry 1280 1024 1280 1024 32 + timings 7408 248 16 38 1 144 3 hsync high vsync high endmode +# +# 1280x1024, 85 Hz, Non-Interlaced (157.50 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 1024 +# Scan Frequency 91.146 kHz 85.02 Hz +# Sync Width 1.016 us 0.033 ms +# 20 chars 3 lines +# Front Porch 0.406 us 0.011 ms +# 8 chars 1 lines +# Back Porch 1.422 us 0.483 ms +# 28 chars 44 lines +# Active Time 8.127 us 11.235 ms +# 160 chars 1024 lines +# Blank Time 2.844 us 0.527 ms +# 56 chars 48 lines +# Polarity positive positive +# + mode "1280x1024-85" +# D: 157.50 MHz, H: 91.146 kHz, V: 85.02 Hz + geometry 1280 1024 1280 1024 32 + timings 6349 224 64 44 1 160 3 + hsync high vsync high endmode mode "1440x900-60" +# D: 106.500 MHz, H: 55.935 kHz, V: 60.00 Hz + geometry 1440 900 1440 900 32 + timings 9390 232 80 25 3 152 6 + hsync high vsync high endmode mode "1440x900-75" +# D: 136.750 MHz, H: 70.635 kHz, V: 75.00 Hz + geometry 1440 900 1440 900 32 + timings 7315 248 96 33 3 152 6 hsync high vsync high endmode +# +# 1440x1050, 60 Hz, Non-Interlaced (125.10 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1440 1050 +# Scan Frequency 65.220 kHz 60.00 Hz +# Sync Width 1.204 us 0.046 ms +# 19 chars 3 lines +# Front Porch 0.760 us 0.015 ms +# 12 chars 1 lines +# Back Porch 1.964 us 0.495 ms +# 31 chars 33 lines +# Active Time 11.405 us 16.099 ms +# 180 chars 1050 lines +# Blank Time 3.928 us 0.567 ms +# 62 chars 37 lines +# Polarity positive positive +# + mode "1440x1050-60" +# D: 125.10 MHz, H: 65.220 kHz, V: 60.00 Hz + geometry 1440 1050 1440 1050 32 + timings 7993 248 96 33 1 152 3 + hsync high vsync high endmode mode "1600x900-60" +# D: 118.250 MHz, H: 55.990 kHz, V: 60.00 Hz + geometry 1600 900 1600 900 32 + timings 8415 256 88 26 3 168 5 endmode mode "1600x1024-60" +# D: 136.358 MHz, H: 63.600 kHz, V: 60.00 Hz + geometry 1600 1024 1600 1024 32 timings 7315 272 104 32 1 168 3 endmode +# +# 1600x1200, 60 Hz, Non-Interlaced (156.00 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1600 1200 +# Scan Frequency 76.200 kHz 60.00 Hz +# Sync Width 1.026 us 0.105 ms +# 20 chars 8 lines +# Front Porch 0.205 us 0.131 ms +# 4 chars 10 lines +# Back Porch 1.636 us 0.682 ms +# 32 chars 52 lines +# Active Time 10.256 us 15.748 ms +# 200 chars 1200 lines +# Blank Time 2.872 us 0.866 ms +# 56 chars 66 lines +# Polarity negative negative +# + mode "1600x1200-60" +# D: 156.00 MHz, H: 76.200 kHz, V: 60.00 Hz + geometry 1600 1200 1600 1200 32 timings 6172 256 32 52 10 160 8 endmode +# +# 1600x1200, 75 Hz, Non-Interlaced (202.50 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1600 1200 +# Scan Frequency 93.750 kHz 75.00 Hz +# Sync Width 0.948 us 0.032 ms +# 24 chars 3 lines +# Front Porch 0.316 us 0.011 ms +# 8 chars 1 lines +# Back Porch 1.501 us 0.491 ms +# 38 chars 46 lines +# Active Time 7.901 us 12.800 ms +# 200 chars 1200 lines +# Blank Time 2.765 us 0.533 ms +# 70 chars 50 lines +# Polarity positive positive +# + mode "1600x1200-75" +# D: 202.50 MHz, H: 93.750 kHz, V: 75.00 Hz + geometry 1600 1200 1600 1200 32 + timings 4938 304 64 46 1 192 3 + hsync high vsync high endmode mode "1680x1050-60" +# D: 146.250 MHz, H: 65.290 kHz, V: 59.954 Hz + geometry 1680 1050 1680 1050 32 + timings 6814 280 104 30 3 176 6 + hsync high vsync high endmode mode "1680x1050-75" +# D: 187.000 MHz, H: 82.306 kHz, V: 74.892 Hz + geometry 1680 1050 1680 1050 32 + timings 5348 296 120 40 3 176 6 + hsync high vsync high endmode mode "1792x1344-60" +# D: 202.975 MHz, H: 83.460 kHz, V: 60.00 Hz + geometry 1792 1344 1792 1344 32 + timings 4902 320 128 43 1 192 3 + hsync high vsync high endmode mode "1856x1392-60" +# D: 218.571 MHz, H: 86.460 kHz, V: 60.00 Hz + geometry 1856 1392 1856 1392 32 + timings 4577 336 136 45 1 200 3 + hsync high vsync high endmode mode "1920x1200-60" +# D: 193.250 MHz, H: 74.556 kHz, V: 60.00 Hz + geometry 1920 1200 1920 1200 32 + timings 5173 336 136 36 3 200 6 + hsync high vsync high endmode mode "1920x1440-60" +# D: 234.000 MHz, H:90.000 kHz, V: 60.00 Hz + geometry 1920 1440 1920 1440 32 + timings 4274 344 128 56 1 208 3 + hsync high vsync high endmode mode "1920x1440-75" +# D: 297.000 MHz, H:112.500 kHz, V: 75.00 Hz + geometry 1920 1440 1920 1440 32 + timings 3367 352 144 56 1 224 3 + hsync high vsync high endmode mode "2048x1536-60" +# D: 267.250 MHz, H: 95.446 kHz, V: 60.00 Hz + geometry 2048 1536 2048 1536 32 + timings 3742 376 152 49 3 224 4 hsync high vsync high endmode +# +# 1280x720, 60 Hz, Non-Interlaced (74.481 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1280 720 +# Scan Frequency 44.760 kHz 60.00 Hz +# Sync Width 1.826 us 67.024 ms +# 17 chars 3 lines +# Front Porch 0.752 us 22.341 ms +# 7 chars 1 lines +# Back Porch 2.578 us 491.510 ms +# 24 chars 22 lines +# Active Time 17.186 us 16.086 ms +# 160 chars 720 lines +# Blank Time 5.156 us 0.581 ms +# 48 chars 26 lines +# Polarity negative negative +# + mode "1280x720-60" +# D: 74.481 MHz, H: 44.760 kHz, V: 60.00 Hz + geometry 1280 720 1280 720 32 timings 13426 192 64 22 1 136 3 endmode +# +# 1920x1080, 60 Hz, Non-Interlaced (172.798 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1920 1080 +# Scan Frequency 67.080 kHz 60.00 Hz +# Sync Width 1.204 us 44.723 ms +# 26 chars 3 lines +# Front Porch 0.694 us 14.908 ms +# 15 chars 1 lines +# Back Porch 1.898 us 506.857 ms +# 41 chars 34 lines +# Active Time 11.111 us 16.100 ms +# 240 chars 1080 lines +# Blank Time 3.796 us 0.566 ms +# 82 chars 38 lines +# Polarity negative negative +# + mode "1920x1080-60" +# D: 74.481 MHz, H: 67.080 kHz, V: 60.00 Hz + geometry 1920 1080 1920 1080 32 timings 5787 328 120 34 1 208 3 endmode +# +# 1400x1050, 60 Hz, Non-Interlaced (122.61 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1400 1050 +# Scan Frequency 65.218 kHz 59.99 Hz +# Sync Width 1.037 us 0.047 ms +# 19 chars 3 lines +# Front Porch 0.444 us 0.015 ms +# 11 chars 1 lines +# Back Porch 1.185 us 0.188 ms +# 30 chars 33 lines +# Active Time 12.963 us 16.411 ms +# 175 chars 1050 lines +# Blank Time 2.667 us 0.250 ms +# 60 chars 37 lines +# Polarity negative positive +# + mode "1400x1050-60" +# D: 122.750 MHz, H: 65.317 kHz, V: 59.99 Hz + geometry 1400 1050 1408 1050 32 + timings 8214 232 88 32 3 144 4 endmode mode "1400x1050-75" +# D: 156.000 MHz, H: 82.278 kHz, V: 74.867 Hz + geometry 1400 1050 1408 1050 32 timings 6410 248 104 42 3 144 4 endmode +# +# 1366x768, 60 Hz, Non-Interlaced (85.86 MHz dotclock) +# +# Horizontal Vertical +# Resolution 1366 768 +# Scan Frequency 47.700 kHz 60.00 Hz +# Sync Width 1.677 us 0.063 ms +# 18 chars 3 lines +# Front Porch 0.839 us 0.021 ms +# 9 chars 1 lines +# Back Porch 2.516 us 0.482 ms +# 27 chars 23 lines +# Active Time 15.933 us 16.101 ms +# 171 chars 768 lines +# Blank Time 5.031 us 0.566 ms +# 54 chars 27 lines +# Polarity negative positive +# + mode "1360x768-60" +# D: 84.750 MHz, H: 47.720 kHz, V: 60.00 Hz + geometry 1360 768 1360 768 32 + timings 11799 208 72 22 3 136 5 endmode mode "1366x768-60" +# D: 85.86 MHz, H: 47.700 kHz, V: 60.00 Hz + geometry 1366 768 1366 768 32 + timings 11647 216 72 23 1 144 3 endmode mode "1366x768-50" +# D: 69,924 MHz, H: 39.550 kHz, V: 50.00 Hz + geometry 1366 768 1366 768 32 timings 14301 200 56 19 1 144 3 endmode diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt new file mode 100644 index 00000000000..1cb2462a71c --- /dev/null +++ b/Documentation/fb/viafb.txt @@ -0,0 +1,252 @@ + + VIA Integration Graphic Chip Console Framebuffer Driver + +[Platform] +----------------------- + The console framebuffer driver is for graphics chips of + VIA UniChrome Family(CLE266, PM800 / CN400 / CN300, + P4M800CE / P4M800Pro / CN700 / VN800, + CX700 / VX700, K8M890, P4M890, + CN896 / P4M900, VX800, VX855) + +[Driver features] +------------------------ + Device: CRT, LCD, DVI + + Support viafb_mode: + CRT: + 640x480(60, 75, 85, 100, 120 Hz), 720x480(60 Hz), + 720x576(60 Hz), 800x600(60, 75, 85, 100, 120 Hz), + 848x480(60 Hz), 856x480(60 Hz), 1024x512(60 Hz), + 1024x768(60, 75, 85, 100 Hz), 1152x864(75 Hz), + 1280x768(60 Hz), 1280x960(60 Hz), 1280x1024(60, 75, 85 Hz), + 1440x1050(60 Hz), 1600x1200(60, 75 Hz), 1280x720(60 Hz), + 1920x1080(60 Hz), 1400x1050(60 Hz), 800x480(60 Hz) + + color depth: 8 bpp, 16 bpp, 32 bpp supports. + + Support 2D hardware accelerator. + +[Using the viafb module] +-- -- -------------------- + Start viafb with default settings: + #modprobe viafb + + Start viafb with user options: + #modprobe viafb viafb_mode=800x600 viafb_bpp=16 viafb_refresh=60 + viafb_active_dev=CRT+DVI viafb_dvi_port=DVP1 + viafb_mode1=1024x768 viafb_bpp=16 viafb_refresh1=60 + viafb_SAMM_ON=1 + + viafb_mode: + 640x480 (default) + 720x480 + 800x600 + 1024x768 + ...... + + viafb_bpp: + 8, 16, 32 (default:32) + + viafb_refresh: + 60, 75, 85, 100, 120 (default:60) + + viafb_lcd_dsp_method: + 0 : expansion (default) + 1 : centering + + viafb_lcd_mode: + 0 : LCD panel with LSB data format input (default) + 1 : LCD panel with MSB data format input + + viafb_lcd_panel_id: + 0 : Resolution: 640x480, Channel: single, Dithering: Enable + 1 : Resolution: 800x600, Channel: single, Dithering: Enable + 2 : Resolution: 1024x768, Channel: single, Dithering: Enable (default) + 3 : Resolution: 1280x768, Channel: single, Dithering: Enable + 4 : Resolution: 1280x1024, Channel: dual, Dithering: Enable + 5 : Resolution: 1400x1050, Channel: dual, Dithering: Enable + 6 : Resolution: 1600x1200, Channel: dual, Dithering: Enable + + 8 : Resolution: 800x480, Channel: single, Dithering: Enable + 9 : Resolution: 1024x768, Channel: dual, Dithering: Enable + 10: Resolution: 1024x768, Channel: single, Dithering: Disable + 11: Resolution: 1024x768, Channel: dual, Dithering: Disable + 12: Resolution: 1280x768, Channel: single, Dithering: Disable + 13: Resolution: 1280x1024, Channel: dual, Dithering: Disable + 14: Resolution: 1400x1050, Channel: dual, Dithering: Disable + 15: Resolution: 1600x1200, Channel: dual, Dithering: Disable + 16: Resolution: 1366x768, Channel: single, Dithering: Disable + 17: Resolution: 1024x600, Channel: single, Dithering: Enable + 18: Resolution: 1280x768, Channel: dual, Dithering: Enable + 19: Resolution: 1280x800, Channel: single, Dithering: Enable + + viafb_accel: + 0 : No 2D Hardware Acceleration + 1 : 2D Hardware Acceleration (default) + + viafb_SAMM_ON: + 0 : viafb_SAMM_ON disable (default) + 1 : viafb_SAMM_ON enable + + viafb_mode1: (secondary display device) + 640x480 (default) + 720x480 + 800x600 + 1024x768 + ... ... + + viafb_bpp1: (secondary display device) + 8, 16, 32 (default:32) + + viafb_refresh1: (secondary display device) + 60, 75, 85, 100, 120 (default:60) + + viafb_active_dev: + This option is used to specify active devices.(CRT, DVI, CRT+LCD...) + DVI stands for DVI or HDMI, E.g., If you want to enable HDMI, + set viafb_active_dev=DVI. In SAMM case, the previous of + viafb_active_dev is primary device, and the following is + secondary device. + + For example: + To enable one device, such as DVI only, we can use: + modprobe viafb viafb_active_dev=DVI + To enable two devices, such as CRT+DVI: + modprobe viafb viafb_active_dev=CRT+DVI; + + For DuoView case, we can use: + modprobe viafb viafb_active_dev=CRT+DVI + OR + modprobe viafb viafb_active_dev=DVI+CRT... + + For SAMM case: + If CRT is primary and DVI is secondary, we should use: + modprobe viafb viafb_active_dev=CRT+DVI viafb_SAMM_ON=1... + If DVI is primary and CRT is secondary, we should use: + modprobe viafb viafb_active_dev=DVI+CRT viafb_SAMM_ON=1... + + viafb_display_hardware_layout: + This option is used to specify display hardware layout for CX700 chip. + 1 : LCD only + 2 : DVI only + 3 : LCD+DVI (default) + 4 : LCD1+LCD2 (internal + internal) + 16: LCD1+ExternalLCD2 (internal + external) + + viafb_second_size: + This option is used to set second device memory size(MB) in SAMM case. + The minimal size is 16. + + viafb_platform_epia_dvi: + This option is used to enable DVI on EPIA - M + 0 : No DVI on EPIA - M (default) + 1 : DVI on EPIA - M + + viafb_bus_width: + When using 24 - Bit Bus Width Digital Interface, + this option should be set. + 12: 12-Bit LVDS or 12-Bit TMDS (default) + 24: 24-Bit LVDS or 24-Bit TMDS + + viafb_device_lcd_dualedge: + When using Dual Edge Panel, this option should be set. + 0 : No Dual Edge Panel (default) + 1 : Dual Edge Panel + + viafb_lcd_port: + This option is used to specify LCD output port, + available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW". + for external LCD + external DVI on CX700(External LCD is on DVP0), + we should use: + modprobe viafb viafb_lcd_port=DVP0... + +Notes: + 1. CRT may not display properly for DuoView CRT & DVI display at + the "640x480" PAL mode with DVI overscan enabled. + 2. SAMM stands for single adapter multi monitors. It is different from + multi-head since SAMM support multi monitor at driver layers, thus fbcon + layer doesn't even know about it; SAMM's second screen doesn't have a + device node file, thus a user mode application can't access it directly. + When SAMM is enabled, viafb_mode and viafb_mode1, viafb_bpp and + viafb_bpp1, viafb_refresh and viafb_refresh1 can be different. + 3. When console is depending on viafbinfo1, dynamically change resolution + and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE + instead of calling common ioctl function FBIOPUT_VSCREENINFO since + viafb doesn't support multi-head well, or it will cause screen crush. + + +[Configure viafb with "fbset" tool] +----------------------------------- + "fbset" is an inbox utility of Linux. + 1. Inquire current viafb information, type, + # fbset -i + + 2. Set various resolutions and viafb_refresh rates, + # fbset <resolution-vertical_sync> + + example, + # fbset "1024x768-75" + or + # fbset -g 1024 768 1024 768 32 + Check the file "/etc/fb.modes" to find display modes available. + + 3. Set the color depth, + # fbset -depth <value> + + example, + # fbset -depth 16 + + +[Configure viafb via /proc] +--------------------------- + The following files exist in /proc/viafb + + supported_output_devices + + This read-only file contains a full ',' separated list containing all + output devices that could be available on your platform. It is likely + that not all of those have a connector on your hardware but it should + provide a good starting point to figure out which of those names match + a real connector. + Example: + # cat /proc/viafb/supported_output_devices + + iga1/output_devices + iga2/output_devices + + These two files are readable and writable. iga1 and iga2 are the two + independent units that produce the screen image. Those images can be + forwarded to one or more output devices. Reading those files is a way + to query which output devices are currently used by an iga. + Example: + # cat /proc/viafb/iga1/output_devices + If there are no output devices printed the output of this iga is lost. + This can happen for example if only one (the other) iga is used. + Writing to these files allows adjusting the output devices during + runtime. One can add new devices, remove existing ones or switch + between igas. Essentially you can write a ',' separated list of device + names (or a single one) in the same format as the output to those + files. You can add a '+' or '-' as a prefix allowing simple addition + and removal of devices. So a prefix '+' adds the devices from your list + to the already existing ones, '-' removes the listed devices from the + existing ones and if no prefix is given it replaces all existing ones + with the listed ones. If you remove devices they are expected to turn + off. If you add devices that are already part of the other iga they are + removed there and added to the new one. + Examples: + Add CRT as output device to iga1 + # echo +CRT > /proc/viafb/iga1/output_devices + + Remove (turn off) DVP1 and LVDS1 as output devices of iga2 + # echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices + + Replace all iga1 output devices by CRT + # echo CRT > /proc/viafb/iga1/output_devices + + +[Bootup with viafb]: +-------------------- + Add the following line to your grub.conf: + append = "video=viafb:viafb_mode=1024x768,viafb_bpp=32,viafb_refresh=85" + |