matroxfb.txt

ARM 嵌入式 系统 设计与实例开发 实验教材 二源码

	    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.
nocross4MB - pixel line must not cross 4MB boundary. It is default for
             Millenium 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.
dfp      - enables digital flat panel interface. This option is incompatible with
           secondary (TV) output - if DFP is active, TV output must be
	   inactive and vice versa. DFP always uses same timing as primary
	   (monitor) output.
dfp:X    - use settings X for digital flat panel interface. X is number from
           0 to 0xFF, and meaning of each individual bit is described in
	   G400 manual, in description of DAC register 0x1F. For normal operation
	   you should set all bits to zero, except lowest bit. This lowest bit
	   selects who is source of display clocks, whether G400, or panel.
	   Default value is now read back from hardware - so you should specify
	   this value only if you are also using `init' parameter.
vesa:X   - selects startup videomode. X is number from 0 to 0x1FF, see table
           above for detailed explanation. Default is 640x480x8bpp if driver
	   has 8bpp support. Otherwise first available of 640x350x4bpp,
	   640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
	   (80x25 text is always available).

If you are not satisfied with videomode selected by `vesa' option, you
can modify it with these options:

xres:X   - horizontal resolution, in pixels. Default is derived from `vesa'
           option.
yres:X   - vertical resolution, in pixel lines. Default is derived from `vesa'
           option.
upper:X  - top boundary: lines between end of VSYNC pulse and start of first
           pixel line of picture. Default is derived from `vesa' option.
lower:X  - bottom boundary: lines between end of picture and start of VSYNC
           pulse. Default is derived from `vesa' option.
vslen:X  - length of VSYNC pulse, in lines. Default is derived from `vesa'
           option.
left:X   - left boundary: pixels between end of HSYNC pulse and first pixel.
           Default is derived from `vesa' option.
right:X  - right boundary: pixels between end of picture and start of HSYNC
           pulse. Default is derived from `vesa' option.
hslen:X  - length of HSYNC pulse, in pixels. Default is derived from `vesa'
           option.
pixclock:X - dotclocks, in ps (picoseconds). Default is derived from `vesa'
             option and from `fh' and `fv' options.
sync:X   - sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
           If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
	   generated. If bit 5 (value 0x20) is set, sync on green is turned on.
	   Do not forget that if you want sync on green, you also probably
	   want composite sync.
	   Default depends on `vesa'.
depth:X  - Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
           `vesa'.

If you know capabilities of your monitor, you can specify some (or all) of
`maxclk', `fh' and `fv'. In this case, `pixclock' is computed so that
pixclock <= maxclk, real_fh <= fh and real_fv <= fv.

maxclk:X - maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
           `don't care'.
fh:X     - maximum horizontal synchronization frequency. X can be specified
           in kHz or Hz. Default is `don't care'.
fv:X     - maximum vertical frequency. X must be specified in Hz. Default is
           70 for modes derived from `vesa' with yres <= 400, 60Hz for
	   yres > 400.


Limitations
===========

There are known and unknown bugs, features and misfeatures.
Currently there are following known bugs:
 + SVGALib does not restore screen on exit
 + generic fbcon-cfbX procedures do not work on Alphas. Due to this,
   `noaccel' (and cfb4 accel) driver does not work on Alpha. So everyone
   with access to /dev/fb* on Alpha can hang machine (you should restrict
   access to /dev/fb* - everyone with access to this device can destroy
   your monitor, believe me...).
 + 24bpp does not support correctly XF-FBDev on big-endian architectures.
 + interlaced text mode is not supported; it looks like hardware limitation,
   but I'm not sure.
 + Gxx0 SGRAM/SDRAM is not autodetected.
 + If you are using more than one framebuffer device, you must boot kernel
   with 'video=scrollback:0'.
 + maybe more...
And following misfeatures:
 + SVGALib does not restore screen on exit.
 + pixclock for text modes is limited by hardware to
    83 MHz on G200
    66 MHz on Millennium I
    60 MHz on Millennium II
   Because I have no access to other devices, I do not know specific
   frequencies for them. So driver does not check this and allows you to
   set frequency higher that this. It causes sparks, black holes and other
   pretty effects on screen. Device was not destroyed during tests. :-)
 + my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
   (and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
   But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
   them (maybe that chip overheats, but it has a very big cooler (G100 has
   none), so it should work).
 + special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
   G16V16 are not supported
 + color keying is not supported
 + feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
   by BIOS)
 + DDC (monitor detection) is supported through dualhead driver
 + some check for input values are not so strict how it should be (you can
   specify vslen=4000 and so on).
 + maybe more...
And following features:
 + 4bpp is available only on Millennium I and Millennium II. It is hardware
   limitation.
 + selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba 
   option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
   else selects 5:6:5 mode.
 + text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
   instead of one of 16M colors). It is due to hardware limitation of 
   Millennium I/II and SVGALib compatibility.


Benchmarks
==========
It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
time for draw 6144000 characters on screen through /dev/vcsa
(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in 
16 seconds, i.e. 187 MBps).
Times were obtained from one older version of driver, now they are about 3%
faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
PCI slot, G200 in AGP 2x slot. I did not test vgacon.

NOACCEL
        8x16                 12x22
        Millennium I  G200   Millennium I  G200
8bpp    16.42         9.54   12.33         9.13
16bpp   21.00        15.70   19.11        15.02
24bpp   36.66        36.66   35.00        35.00
32bpp   35.00        30.00   33.85        28.66

ACCEL, nofastfont
        8x16                 12x22                6x11
	Millennium I  G200   Millennium I  G200   Millennium I  G200
8bpp     7.79         7.24   13.55         7.78   30.00        21.01
16bpp    9.13         7.78   16.16         7.78   30.00        21.01
24bpp   14.17        10.72   18.69        10.24   34.99        21.01
32bpp   16.15	     16.16   18.73        13.09   34.99        21.01

ACCEL, fastfont
        8x16                 12x22                6x11
	Millennium I  G200   Millennium I  G200   Millennium I  G200
8bpp     8.41         6.01    6.54         4.37   16.00        10.51
16bpp    9.54         9.12    8.76         6.17   17.52        14.01
24bpp   15.00        12.36   11.67        10.00   22.01        18.32
32bpp   16.18        18.29*  12.71        12.74   24.44        21.00

TEXT
        8x16
	Millennium I  G200
TEXT     3.29         1.50

* Yes, it is slower than Millennium I.


Dualhead G400
=============
Driver supports dualhead G400 with some limitations:
 + secondary head shares videomemory with primary head. It is not problem
   if you have 32MB of videoram, but if you have only 16MB, you may have
   to think twice before choosing videomode (for example twice 1880x1440x32bpp
   is not possible).
 + due to hardware limitation, secondary head can use only 16 and 32bpp
   videomodes.
 + secondary head is not accelerated. There were bad problems with accelerated
   XFree when secondary head used to use acceleration.
 + secondary head always powerups in 640x480@60-32 videomode. You have to use
   fbset to change this mode.
 + secondary head always powerups in monitor mode. You have to use matroxset
   to change it to TV mode. Also, you must select at least 525 lines for
   NTSC output and 625 lines for PAL output.
 + kernel is not fully multihead ready. So some things are impossible to do.
 + if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
   and matroxfb_crtc2 into kernel.


Dualhead G450
=============
Driver supports dualhead G450 with some limitations:
 + secondary head shares videomemory with primary head. It is not problem
   if you have 32MB of videoram, but if you have only 16MB, you may have
   to think twice before choosing videomode.
 + due to hardware limitation, secondary head can use only 16 and 32bpp
   videomodes.
 + secondary head is not accelerated.
 + secondary head always powerups in 640x480@60-32 videomode. You have to use
   fbset to change this mode.
 + TV output is not supported
 + kernel is not fully multihead ready, so some things are impossible to do.
 + if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
   into kernel.
	
--
Petr Vandrovec <[e-mail]>