Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
This commit is contained in:
Linus Torvalds
25
Documentation/fb/00-INDEX
Normal file
25
Documentation/fb/00-INDEX
Normal file
@@ -0,0 +1,25 @@
|
||||
Index of files in Documentation/fb. If you think something about frame
|
||||
buffer devices needs an entry here, needs correction or you've written one
|
||||
please mail me.
|
||||
Geert Uytterhoeven <geert@linux-m68k.org>
|
||||
|
||||
00-INDEX
|
||||
- this file
|
||||
framebuffer.txt
|
||||
- introduction to frame buffer devices
|
||||
internals.txt
|
||||
- quick overview of frame buffer device internals
|
||||
modedb.txt
|
||||
- info on the video mode database
|
||||
aty128fb.txt
|
||||
- info on the ATI Rage128 frame buffer driver
|
||||
clgenfb.txt
|
||||
- info on the Cirrus Logic frame buffer driver
|
||||
matroxfb.txt
|
||||
- info on the Matrox frame buffer driver
|
||||
pvr2fb.txt
|
||||
- info on the PowerVR 2 frame buffer driver
|
||||
tgafb.txt
|
||||
- info on the TGA (DECChip 21030) frame buffer driver
|
||||
vesafb.txt
|
||||
- info on the VESA frame buffer device
|
||||
72
Documentation/fb/aty128fb.txt
Normal file
72
Documentation/fb/aty128fb.txt
Normal file
@@ -0,0 +1,72 @@
|
||||
[This file is cloned from VesaFB/matroxfb]
|
||||
|
||||
What is aty128fb?
|
||||
=================
|
||||
|
||||
This is a driver for a graphic framebuffer for ATI Rage128 based devices
|
||||
on Intel and PPC boxes.
|
||||
|
||||
Advantages:
|
||||
|
||||
* It provides a nice large console (128 cols + 48 lines with 1024x768)
|
||||
without using tiny, unreadable fonts.
|
||||
* You can run XF68_FBDev on top of /dev/fb0
|
||||
* Most important: boot logo :-)
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* graphic mode is slower than text mode... but you should not notice
|
||||
if you use same resolution as you used in textmode.
|
||||
* still experimental.
|
||||
|
||||
|
||||
How to use it?
|
||||
==============
|
||||
|
||||
Switching modes is done using the video=aty128fb:<resolution>... modedb
|
||||
boot parameter or using `fbset' program.
|
||||
|
||||
See Documentation/fb/modedb.txt for more information on modedb
|
||||
resolutions.
|
||||
|
||||
You should compile in both vgacon (to boot if you remove your Rage128 from
|
||||
box) and aty128fb (for graphics mode). You should not compile-in vesafb
|
||||
unless you have primary display on non-Rage128 VBE2.0 device (see
|
||||
Documentation/fb/vesafb.txt for details).
|
||||
|
||||
|
||||
X11
|
||||
===
|
||||
|
||||
XF68_FBDev should generally work fine, but it is non-accelerated. As of
|
||||
this document, 8 and 32bpp works fine. There have been palette issues
|
||||
when switching from X to console and back to X. You will have to restart
|
||||
X to fix this.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
You can pass kernel command line options to vesafb with
|
||||
`video=aty128fb:option1,option2:value2,option3' (multiple options should
|
||||
be separated by comma, values are separated from options by `:').
|
||||
Accepted options:
|
||||
|
||||
noaccel - do not use acceleration engine. It is default.
|
||||
accel - use acceleration engine. Not finished.
|
||||
vmode:x - chooses PowerMacintosh video mode <x>. Depreciated.
|
||||
cmode:x - chooses PowerMacintosh colour mode <x>. Depreciated.
|
||||
<XxX@X> - selects startup videomode. See modedb.txt for detailed
|
||||
explanation. Default is 640x480x8bpp.
|
||||
|
||||
|
||||
Limitations
|
||||
===========
|
||||
|
||||
There are known and unknown bugs, features and misfeatures.
|
||||
Currently there are following known bugs:
|
||||
+ This driver is still experimental and is not finished. Too many
|
||||
bugs/errata to list here.
|
||||
|
||||
--
|
||||
Brad Douglas <brad@neruo.com>
|
||||
97
Documentation/fb/cirrusfb.txt
Normal file
97
Documentation/fb/cirrusfb.txt
Normal file
@@ -0,0 +1,97 @@
|
||||
|
||||
Framebuffer driver for Cirrus Logic chipsets
|
||||
Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
|
||||
|
||||
|
||||
|
||||
{ just a little something to get people going; contributors welcome! }
|
||||
|
||||
|
||||
|
||||
Chip families supported:
|
||||
SD64
|
||||
Piccolo
|
||||
Picasso
|
||||
Spectrum
|
||||
Alpine (GD-543x/4x)
|
||||
Picasso4 (GD-5446)
|
||||
GD-5480
|
||||
Laguna (GD-546x)
|
||||
|
||||
Bus's supported:
|
||||
PCI
|
||||
Zorro
|
||||
|
||||
Architectures supported:
|
||||
i386
|
||||
Alpha
|
||||
PPC (Motorola Powerstack)
|
||||
m68k (Amiga)
|
||||
|
||||
|
||||
|
||||
Default video modes
|
||||
-------------------
|
||||
At the moment, there are two kernel command line arguments supported:
|
||||
|
||||
mode:640x480
|
||||
mode:800x600
|
||||
or
|
||||
mode:1024x768
|
||||
|
||||
Full support for startup video modes (modedb) will be integrated soon.
|
||||
|
||||
Version 1.9.9.1
|
||||
---------------
|
||||
* Fix memory detection for 512kB case
|
||||
* 800x600 mode
|
||||
* Fixed timings
|
||||
* Hint for AXP: Use -accel false -vyres -1 when changing resolution
|
||||
|
||||
|
||||
Version 1.9.4.4
|
||||
---------------
|
||||
* Preliminary Laguna support
|
||||
* 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.
|
||||
* Code cleanup, add comments.
|
||||
* Overhaul SR07 handling.
|
||||
* Bug fixes.
|
||||
|
||||
|
||||
Version 1.9.4.3
|
||||
---------------
|
||||
* Correctly set default startup video mode.
|
||||
* Do not override ram size setting. Define
|
||||
CLGEN_USE_HARDCODED_RAM_SETTINGS if you _do_ want to override the RAM
|
||||
setting.
|
||||
* Compile fixes related to new 2.3.x IORESOURCE_IO[PORT] symbol changes.
|
||||
* Use new 2.3.x resource allocation.
|
||||
* Some code cleanup.
|
||||
|
||||
|
||||
Version 1.9.4.2
|
||||
---------------
|
||||
* Casting fixes.
|
||||
* Assertions no longer cause an oops on purpose.
|
||||
* Bug fixes.
|
||||
|
||||
|
||||
Version 1.9.4.1
|
||||
---------------
|
||||
* Add compatibility support. Now requires a 2.1.x, 2.2.x or 2.3.x kernel.
|
||||
|
||||
|
||||
Version 1.9.4
|
||||
-------------
|
||||
* Several enhancements, smaller memory footprint, a few bugfixes.
|
||||
* Requires kernel 2.3.14-pre1 or later.
|
||||
|
||||
|
||||
Version 1.9.3
|
||||
-------------
|
||||
* Bundled with kernel 2.3.14-pre1 or later.
|
||||
|
||||
|
||||
345
Documentation/fb/framebuffer.txt
Normal file
345
Documentation/fb/framebuffer.txt
Normal file
@@ -0,0 +1,345 @@
|
||||
The Frame Buffer Device
|
||||
-----------------------
|
||||
|
||||
Maintained by Geert Uytterhoeven <geert@linux-m68k.org>
|
||||
Last revised: May 10, 2001
|
||||
|
||||
|
||||
0. Introduction
|
||||
---------------
|
||||
|
||||
The frame buffer device provides an abstraction for the graphics hardware. It
|
||||
represents the frame buffer of some video hardware and allows application
|
||||
software to access the graphics hardware through a well-defined interface, so
|
||||
the software doesn't need to know anything about the low-level (hardware
|
||||
register) stuff.
|
||||
|
||||
The device is accessed through special device nodes, usually located in the
|
||||
/dev directory, i.e. /dev/fb*.
|
||||
|
||||
|
||||
1. User's View of /dev/fb*
|
||||
--------------------------
|
||||
|
||||
From the user's point of view, the frame buffer device looks just like any
|
||||
other device in /dev. It's a character device using major 29; the minor
|
||||
specifies the frame buffer number.
|
||||
|
||||
By convention, the following device nodes are used (numbers indicate the device
|
||||
minor numbers):
|
||||
|
||||
0 = /dev/fb0 First frame buffer
|
||||
1 = /dev/fb1 Second frame buffer
|
||||
...
|
||||
31 = /dev/fb31 32nd frame buffer
|
||||
|
||||
For backwards compatibility, you may want to create the following symbolic
|
||||
links:
|
||||
|
||||
/dev/fb0current -> fb0
|
||||
/dev/fb1current -> fb1
|
||||
|
||||
and so on...
|
||||
|
||||
The frame buffer devices are also `normal' memory devices, this means, you can
|
||||
read and write their contents. You can, for example, make a screen snapshot by
|
||||
|
||||
cp /dev/fb0 myfile
|
||||
|
||||
There also can be more than one frame buffer at a time, e.g. if you have a
|
||||
graphics card in addition to the built-in hardware. The corresponding frame
|
||||
buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.
|
||||
|
||||
Application software that uses the frame buffer device (e.g. the X server) will
|
||||
use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
|
||||
an alternative frame buffer device by setting the environment variable
|
||||
$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
|
||||
users):
|
||||
|
||||
export FRAMEBUFFER=/dev/fb1
|
||||
|
||||
or (for csh users):
|
||||
|
||||
setenv FRAMEBUFFER /dev/fb1
|
||||
|
||||
After this the X server will use the second frame buffer.
|
||||
|
||||
|
||||
2. Programmer's View of /dev/fb*
|
||||
--------------------------------
|
||||
|
||||
As you already know, a frame buffer device is a memory device like /dev/mem and
|
||||
it has the same features. You can read it, write it, seek to some location in
|
||||
it and mmap() it (the main usage). The difference is just that the memory that
|
||||
appears in the special file is not the whole memory, but the frame buffer of
|
||||
some video hardware.
|
||||
|
||||
/dev/fb* also allows several ioctls on it, by which lots of information about
|
||||
the hardware can be queried and set. The color map handling works via ioctls,
|
||||
too. Look into <linux/fb.h> for more information on what ioctls exist and on
|
||||
which data structures they work. Here's just a brief overview:
|
||||
|
||||
- You can request unchangeable information about the hardware, like name,
|
||||
organization of the screen memory (planes, packed pixels, ...) and address
|
||||
and length of the screen memory.
|
||||
|
||||
- You can request and change variable information about the hardware, like
|
||||
visible and virtual geometry, depth, color map format, timing, and so on.
|
||||
If you try to change that information, the driver maybe will round up some
|
||||
values to meet the hardware's capabilities (or return EINVAL if that isn't
|
||||
possible).
|
||||
|
||||
- You can get and set parts of the color map. Communication is done with 16
|
||||
bits per color part (red, green, blue, transparency) to support all
|
||||
existing hardware. The driver does all the computations needed to apply
|
||||
it to the hardware (round it down to less bits, maybe throw away
|
||||
transparency).
|
||||
|
||||
All this hardware abstraction makes the implementation of application programs
|
||||
easier and more portable. E.g. the X server works completely on /dev/fb* and
|
||||
thus doesn't need to know, for example, how the color registers of the concrete
|
||||
hardware are organized. XF68_FBDev is a general X server for bitmapped,
|
||||
unaccelerated video hardware. The only thing that has to be built into
|
||||
application programs is the screen organization (bitplanes or chunky pixels
|
||||
etc.), because it works on the frame buffer image data directly.
|
||||
|
||||
For the future it is planned that frame buffer drivers for graphics cards and
|
||||
the like can be implemented as kernel modules that are loaded at runtime. Such
|
||||
a driver just has to call register_framebuffer() and supply some functions.
|
||||
Writing and distributing such drivers independently from the kernel will save
|
||||
much trouble...
|
||||
|
||||
|
||||
3. Frame Buffer Resolution Maintenance
|
||||
--------------------------------------
|
||||
|
||||
Frame buffer resolutions are maintained using the utility `fbset'. It can
|
||||
change the video mode properties of a frame buffer device. Its main usage is
|
||||
to change the current video mode, e.g. during boot up in one of your /etc/rc.*
|
||||
or /etc/init.d/* files.
|
||||
|
||||
Fbset uses a video mode database stored in a configuration file, so you can
|
||||
easily add your own modes and refer to them with a simple identifier.
|
||||
|
||||
|
||||
4. The X Server
|
||||
---------------
|
||||
|
||||
The X server (XF68_FBDev) is the most notable application program for the frame
|
||||
buffer device. Starting with XFree86 release 3.2, the X server is part of
|
||||
XFree86 and has 2 modes:
|
||||
|
||||
- If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
|
||||
file contains a
|
||||
|
||||
Modes "default"
|
||||
|
||||
line, the X server will use the scheme discussed above, i.e. it will start
|
||||
up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
|
||||
still have to specify the color depth (using the Depth keyword) and virtual
|
||||
resolution (using the Virtual keyword) though. This is the default for the
|
||||
configuration file supplied with XFree86. It's the most simple
|
||||
configuration, but it has some limitations.
|
||||
|
||||
- Therefore it's also possible to specify resolutions in the /etc/XF86Config
|
||||
file. This allows for on-the-fly resolution switching while retaining the
|
||||
same virtual desktop size. The frame buffer device that's used is still
|
||||
/dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
|
||||
defined by /etc/XF86Config now. The disadvantage is that you have to
|
||||
specify the timings in a different format (but `fbset -x' may help).
|
||||
|
||||
To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
|
||||
work 100% with XF68_FBDev: the reported clock values are always incorrect.
|
||||
|
||||
|
||||
5. Video Mode Timings
|
||||
---------------------
|
||||
|
||||
A monitor draws an image on the screen by using an electron beam (3 electron
|
||||
beams for color models, 1 electron beam for monochrome monitors). The front of
|
||||
the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
|
||||
is hit by an electron, it emits a photon and thus becomes visible.
|
||||
|
||||
The electron beam draws horizontal lines (scanlines) from left to right, and
|
||||
from the top to the bottom of the screen. By modifying the intensity of the
|
||||
electron beam, pixels with various colors and intensities can be shown.
|
||||
|
||||
After each scanline the electron beam has to move back to the left side of the
|
||||
screen and to the next line: this is called the horizontal retrace. After the
|
||||
whole screen (frame) was painted, the beam moves back to the upper left corner:
|
||||
this is called the vertical retrace. During both the horizontal and vertical
|
||||
retrace, the electron beam is turned off (blanked).
|
||||
|
||||
The speed at which the electron beam paints the pixels is determined by the
|
||||
dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
|
||||
of cycles per second), each pixel is 35242 ps (picoseconds) long:
|
||||
|
||||
1/(28.37516E6 Hz) = 35.242E-9 s
|
||||
|
||||
If the screen resolution is 640x480, it will take
|
||||
|
||||
640*35.242E-9 s = 22.555E-6 s
|
||||
|
||||
to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
|
||||
also takes time (e.g. 272 `pixels'), so a full scanline takes
|
||||
|
||||
(640+272)*35.242E-9 s = 32.141E-6 s
|
||||
|
||||
We'll say that the horizontal scanrate is about 31 kHz:
|
||||
|
||||
1/(32.141E-6 s) = 31.113E3 Hz
|
||||
|
||||
A full screen counts 480 (yres) lines, but we have to consider the vertical
|
||||
retrace too (e.g. 49 `lines'). So a full screen will take
|
||||
|
||||
(480+49)*32.141E-6 s = 17.002E-3 s
|
||||
|
||||
The vertical scanrate is about 59 Hz:
|
||||
|
||||
1/(17.002E-3 s) = 58.815 Hz
|
||||
|
||||
This means the screen data is refreshed about 59 times per second. To have a
|
||||
stable picture without visible flicker, VESA recommends a vertical scanrate of
|
||||
at least 72 Hz. But the perceived flicker is very human dependent: some people
|
||||
can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
|
||||
|
||||
Since the monitor doesn't know when a new scanline starts, the graphics board
|
||||
will supply a synchronization pulse (horizontal sync or hsync) for each
|
||||
scanline. Similarly it supplies a synchronization pulse (vertical sync or
|
||||
vsync) for each new frame. The position of the image on the screen is
|
||||
influenced by the moments at which the synchronization pulses occur.
|
||||
|
||||
The following picture summarizes all timings. The horizontal retrace time is
|
||||
the sum of the left margin, the right margin and the hsync length, while the
|
||||
vertical retrace time is the sum of the upper margin, the lower margin and the
|
||||
vsync length.
|
||||
|
||||
+----------+---------------------------------------------+----------+-------+
|
||||
| | ^ | | |
|
||||
| | |upper_margin | | |
|
||||
| | <20> | | |
|
||||
+----------###############################################----------+-------+
|
||||
| # ^ # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| left # | # right | hsync |
|
||||
| margin # | xres # margin | len |
|
||||
|<-------->#<---------------+--------------------------->#<-------->|<----->|
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # |yres # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # | # | |
|
||||
| # <20> # | |
|
||||
+----------###############################################----------+-------+
|
||||
| | ^ | | |
|
||||
| | |lower_margin | | |
|
||||
| | <20> | | |
|
||||
+----------+---------------------------------------------+----------+-------+
|
||||
| | ^ | | |
|
||||
| | |vsync_len | | |
|
||||
| | <20> | | |
|
||||
+----------+---------------------------------------------+----------+-------+
|
||||
|
||||
The frame buffer device expects all horizontal timings in number of dotclocks
|
||||
(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
|
||||
|
||||
|
||||
6. Converting XFree86 timing values info frame buffer device timings
|
||||
--------------------------------------------------------------------
|
||||
|
||||
An XFree86 mode line consists of the following fields:
|
||||
"800x600" 50 800 856 976 1040 600 637 643 666
|
||||
< name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
|
||||
|
||||
The frame buffer device uses the following fields:
|
||||
|
||||
- pixclock: pixel clock in ps (pico seconds)
|
||||
- left_margin: time from sync to picture
|
||||
- right_margin: time from picture to sync
|
||||
- upper_margin: time from sync to picture
|
||||
- lower_margin: time from picture to sync
|
||||
- hsync_len: length of horizontal sync
|
||||
- vsync_len: length of vertical sync
|
||||
|
||||
1) Pixelclock:
|
||||
xfree: in MHz
|
||||
fb: in picoseconds (ps)
|
||||
|
||||
pixclock = 1000000 / DCF
|
||||
|
||||
2) horizontal timings:
|
||||
left_margin = HFL - SH2
|
||||
right_margin = SH1 - HR
|
||||
hsync_len = SH2 - SH1
|
||||
|
||||
3) vertical timings:
|
||||
upper_margin = VFL - SV2
|
||||
lower_margin = SV1 - VR
|
||||
vsync_len = SV2 - SV1
|
||||
|
||||
Good examples for VESA timings can be found in the XFree86 source tree,
|
||||
under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
|
||||
|
||||
|
||||
7. References
|
||||
-------------
|
||||
|
||||
For more specific information about the frame buffer device and its
|
||||
applications, please refer to the Linux-fbdev website:
|
||||
|
||||
http://linux-fbdev.sourceforge.net/
|
||||
|
||||
and to the following documentation:
|
||||
|
||||
- The manual pages for fbset: fbset(8), fb.modes(5)
|
||||
- The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
|
||||
- The mighty kernel sources:
|
||||
o linux/drivers/video/
|
||||
o linux/include/linux/fb.h
|
||||
o linux/include/video/
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
|
||||
subscription information and archive browsing.
|
||||
|
||||
|
||||
9. Downloading
|
||||
--------------
|
||||
|
||||
All necessary files can be found at
|
||||
|
||||
ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
|
||||
|
||||
and on its mirrors.
|
||||
|
||||
The latest version of fbset can be found at
|
||||
|
||||
http://home.tvd.be/cr26864/Linux/fbdev/
|
||||
|
||||
|
||||
10. Credits
|
||||
----------
|
||||
|
||||
This readme was written by Geert Uytterhoeven, partly based on the original
|
||||
`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
|
||||
provided by Frank Neumann.
|
||||
|
||||
The frame buffer device abstraction was designed by Martin Schaller.
|
||||
272
Documentation/fb/intel810.txt
Normal file
272
Documentation/fb/intel810.txt
Normal file
@@ -0,0 +1,272 @@
|
||||
Intel 810/815 Framebuffer driver
|
||||
Tony Daplas <adaplas@pol.net>
|
||||
http://i810fb.sourceforge.net
|
||||
|
||||
March 17, 2002
|
||||
|
||||
First Released: July 2001
|
||||
================================================================
|
||||
|
||||
A. Introduction
|
||||
This is a framebuffer driver for various Intel 810/815 compatible
|
||||
graphics devices. These would include:
|
||||
|
||||
Intel 810
|
||||
Intel 810E
|
||||
Intel 810-DC100
|
||||
Intel 815 Internal graphics only, 100Mhz FSB
|
||||
Intel 815 Internal graphics only
|
||||
Intel 815 Internal graphics and AGP
|
||||
|
||||
B. Features
|
||||
|
||||
- Choice of using Discrete Video Timings, VESA Generalized Timing
|
||||
Formula, or a framebuffer specific database to set the video mode
|
||||
|
||||
- Supports a variable range of horizontal and vertical resolution, and
|
||||
vertical refresh rates if the VESA Generalized Timing Formula is
|
||||
enabled.
|
||||
|
||||
- Supports color depths of 8, 16, 24 and 32 bits per pixel
|
||||
|
||||
- Supports pseudocolor, directcolor, or truecolor visuals
|
||||
|
||||
- Full and optimized hardware acceleration at 8, 16 and 24 bpp
|
||||
|
||||
- Robust video state save and restore
|
||||
|
||||
- MTRR support
|
||||
|
||||
- Utilizes user-entered monitor specifications to automatically
|
||||
calculate required video mode parameters.
|
||||
|
||||
- Can concurrently run with xfree86 running with native i810 drivers
|
||||
|
||||
- Hardware Cursor Support
|
||||
|
||||
C. List of available options
|
||||
|
||||
a. "video=i810fb"
|
||||
enables the i810 driver
|
||||
|
||||
Recommendation: required
|
||||
|
||||
b. "xres:<value>"
|
||||
select horizontal resolution in pixels
|
||||
|
||||
Recommendation: user preference
|
||||
(default = 640)
|
||||
|
||||
c. "yres:<value>"
|
||||
select vertical resolution in scanlines. If Discrete Video Timings
|
||||
is enabled, this will be ignored and computed as 3*xres/4.
|
||||
|
||||
Recommendation: user preference
|
||||
(default = 480)
|
||||
|
||||
d. "vyres:<value>"
|
||||
select virtual vertical resolution in scanlines. If (0) or none
|
||||
is specified, this will be computed against maximum available memory.
|
||||
|
||||
Recommendation: do not set
|
||||
(default = 480)
|
||||
|
||||
e. "vram:<value>"
|
||||
select amount of system RAM in MB to allocate for the video memory
|
||||
|
||||
Recommendation: 1 - 4 MB.
|
||||
(default = 4)
|
||||
|
||||
f. "bpp:<value>"
|
||||
select desired pixel depth
|
||||
|
||||
Recommendation: 8
|
||||
(default = 8)
|
||||
|
||||
g. "hsync1/hsync2:<value>"
|
||||
select the minimum and maximum Horizontal Sync Frequency of the
|
||||
monitor in KHz. If a using a fixed frequency monitor, hsync1 must
|
||||
be equal to hsync2.
|
||||
|
||||
Recommendation: check monitor manual for correct values
|
||||
default (29/30)
|
||||
|
||||
h. "vsync1/vsync2:<value>"
|
||||
select the minimum and maximum Vertical Sync Frequency of the monitor
|
||||
in Hz. You can also use this option to lock your monitor's refresh
|
||||
rate.
|
||||
|
||||
Recommendation: check monitor manual for correct values
|
||||
(default = 60/60)
|
||||
|
||||
IMPORTANT: If you need to clamp your timings, try to give some
|
||||
leeway for computational errors (over/underflows). Example: if
|
||||
using vsync1/vsync2 = 60/60, make sure hsync1/hsync2 has at least
|
||||
a 1 unit difference, and vice versa.
|
||||
|
||||
i. "voffset:<value>"
|
||||
select at what offset in MB of the logical memory to allocate the
|
||||
framebuffer memory. The intent is to avoid the memory blocks
|
||||
used by standard graphics applications (XFree86). The default
|
||||
offset (16 MB for a 64MB aperture, 8 MB for a 32MB aperture) will
|
||||
avoid XFree86's usage and allows up to 7MB/15MB of framebuffer
|
||||
memory. Depending on your usage, adjust the value up or down,
|
||||
(0 for maximum usage, 31/63 MB for the least amount). Note, an
|
||||
arbitrary setting may conflict with XFree86.
|
||||
|
||||
Recommendation: do not set
|
||||
(default = 8 or 16 MB)
|
||||
|
||||
j. "accel"
|
||||
enable text acceleration. This can be enabled/reenabled anytime
|
||||
by using 'fbset -accel true/false'.
|
||||
|
||||
Recommendation: enable
|
||||
(default = not set)
|
||||
|
||||
k. "mtrr"
|
||||
enable MTRR. This allows data transfers to the framebuffer memory
|
||||
to occur in bursts which can significantly increase performance.
|
||||
Not very helpful with the i810/i815 because of 'shared memory'.
|
||||
|
||||
Recommendation: do not set
|
||||
(default = not set)
|
||||
|
||||
l. "extvga"
|
||||
if specified, secondary/external VGA output will always be enabled.
|
||||
Useful if the BIOS turns off the VGA port when no monitor is attached.
|
||||
The external VGA monitor can then be attached without rebooting.
|
||||
|
||||
Recommendation: do not set
|
||||
(default = not set)
|
||||
|
||||
m. "sync"
|
||||
Forces the hardware engine to do a "sync" or wait for the hardware
|
||||
to finish before starting another instruction. This will produce a
|
||||
more stable setup, but will be slower.
|
||||
|
||||
Recommendation: do not set
|
||||
(default = not set)
|
||||
|
||||
n. "dcolor"
|
||||
Use directcolor visual instead of truecolor for pixel depths greater
|
||||
than 8 bpp. Useful for color tuning, such as gamma control.
|
||||
|
||||
Recommendation: do not set
|
||||
(default = not set)
|
||||
|
||||
D. Kernel booting
|
||||
|
||||
Separate each option/option-pair by commas (,) and the option from its value
|
||||
with a colon (:) as in the following:
|
||||
|
||||
video=i810fb:option1,option2:value2
|
||||
|
||||
Sample Usage
|
||||
------------
|
||||
|
||||
In /etc/lilo.conf, add the line:
|
||||
|
||||
append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
|
||||
vsync1:50,vsync2:85,accel,mtrr"
|
||||
|
||||
This will initialize the framebuffer to 1024x768 at 8bpp. The framebuffer
|
||||
will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
|
||||
will be computed based on the hsync1/hsync2 and vsync1/vsync2 values.
|
||||
|
||||
IMPORTANT:
|
||||
You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
|
||||
better than 640x480 at 60Hz.
|
||||
|
||||
E. Module options
|
||||
|
||||
The module parameters are essentially similar to the kernel
|
||||
parameters. The main difference is that you need to include a Boolean value
|
||||
(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
|
||||
|
||||
Example, to enable MTRR, include "mtrr=1".
|
||||
|
||||
Sample Usage
|
||||
------------
|
||||
|
||||
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
|
||||
|
||||
options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
|
||||
vsync2=85 accel=1 mtrr=1
|
||||
|
||||
and just do a
|
||||
|
||||
modprobe i810fb
|
||||
|
||||
|
||||
F. Setup
|
||||
|
||||
a. Do your usual method of configuring the kernel.
|
||||
|
||||
make menuconfig/xconfig/config
|
||||
|
||||
b. Under "Code Maturity Options", enable "Prompt for experimental/
|
||||
incomplete code/drivers".
|
||||
|
||||
c. Enable agpgart support for the Intel 810/815 on-board graphics.
|
||||
This is required. The option is under "Character Devices"
|
||||
|
||||
d. Under "Graphics Support", select "Intel 810/815" either statically
|
||||
or as a module. Choose "use VESA GTF for video timings" if you
|
||||
need to maximize the capability of your display. To be on the
|
||||
safe side, you can leave this unselected.
|
||||
|
||||
e. If you want a framebuffer console, enable it under "Console
|
||||
Drivers"
|
||||
|
||||
f. Compile your kernel.
|
||||
|
||||
g. Load the driver as described in section D and E.
|
||||
|
||||
Optional:
|
||||
h. If you are going to run XFree86 with its native drivers, the
|
||||
standard XFree86 4.1.0 and 4.2.0 drivers should work as is.
|
||||
However, there's a bug in the XFree86 i810 drivers. It attempts
|
||||
to use XAA even when switched to the console. This will crash
|
||||
your server. I have a fix at this site:
|
||||
|
||||
http://i810fb.sourceforge.net.
|
||||
|
||||
You can either use the patch, or just replace
|
||||
|
||||
/usr/X11R6/lib/modules/drivers/i810_drv.o
|
||||
|
||||
with the one provided at the website.
|
||||
|
||||
i. Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver
|
||||
patch to see the chipset in action (or inaction :-).
|
||||
|
||||
G. Acknowledgment:
|
||||
|
||||
1. Geert Uytterhoeven - his excellent howto and the virtual
|
||||
framebuffer driver code made this possible.
|
||||
|
||||
2. Jeff Hartmann for his agpgart code.
|
||||
|
||||
3. The X developers. Insights were provided just by reading the
|
||||
XFree86 source code.
|
||||
|
||||
4. Intel(c). For this value-oriented chipset driver and for
|
||||
providing documentation.
|
||||
|
||||
5. Matt Sottek. His inputs and ideas helped in making some
|
||||
optimizations possible.
|
||||
|
||||
H. Home Page:
|
||||
|
||||
A more complete, and probably updated information is provided at
|
||||
http://i810fb.sourceforge.net.
|
||||
|
||||
###########################
|
||||
Tony
|
||||
|
||||
82
Documentation/fb/internals.txt
Normal file
82
Documentation/fb/internals.txt
Normal file
@@ -0,0 +1,82 @@
|
||||
|
||||
This is a first start for some documentation about frame buffer device
|
||||
internals.
|
||||
|
||||
Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
|
||||
James Simmons <jsimmons@user.sf.net>, Nov 26 2002
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
*** STRUCTURES USED BY THE FRAME BUFFER DEVICE API ***
|
||||
|
||||
The following structures play a role in the game of frame buffer devices. They
|
||||
are defined in <linux/fb.h>.
|
||||
|
||||
1. Outside the kernel (user space)
|
||||
|
||||
- struct fb_fix_screeninfo
|
||||
|
||||
Device independent unchangeable information about a frame buffer device and
|
||||
a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO
|
||||
ioctl.
|
||||
|
||||
- struct fb_var_screeninfo
|
||||
|
||||
Device independent changeable information about a frame buffer device and a
|
||||
specific video mode. This can be obtained using the FBIOGET_VSCREENINFO
|
||||
ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan
|
||||
the screen only, you can use the FBIOPAN_DISPLAY ioctl.
|
||||
|
||||
- struct fb_cmap
|
||||
|
||||
Device independent colormap information. You can get and set the colormap
|
||||
using the FBIOGETCMAP and FBIOPUTCMAP ioctls.
|
||||
|
||||
|
||||
2. Inside the kernel
|
||||
|
||||
- struct fb_info
|
||||
|
||||
Generic information, API and low level information about a specific frame
|
||||
buffer device instance (slot number, board address, ...).
|
||||
|
||||
- struct `par'
|
||||
|
||||
Device dependent information that uniquely defines the video mode for this
|
||||
particular piece of hardware.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
*** VISUALS USED BY THE FRAME BUFFER DEVICE API ***
|
||||
|
||||
|
||||
Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)
|
||||
-------------------------------------------------
|
||||
Each pixel is either black or white.
|
||||
|
||||
|
||||
Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR)
|
||||
---------------------------------------------------------------------
|
||||
The whole pixel value is fed through a programmable lookup table that has one
|
||||
color (including red, green, and blue intensities) for each possible pixel
|
||||
value, and that color is displayed.
|
||||
|
||||
|
||||
True color (FB_VISUAL_TRUECOLOR)
|
||||
--------------------------------
|
||||
The pixel value is broken up into red, green, and blue fields.
|
||||
|
||||
|
||||
Direct color (FB_VISUAL_DIRECTCOLOR)
|
||||
------------------------------------
|
||||
The pixel value is broken up into red, green, and blue fields, each of which
|
||||
are looked up in separate red, green, and blue lookup tables.
|
||||
|
||||
|
||||
Grayscale displays
|
||||
------------------
|
||||
Grayscale and static grayscale are special variants of pseudo color and static
|
||||
pseudo color, where the red, green and blue components are always equal to
|
||||
each other.
|
||||
|
||||
415
Documentation/fb/matroxfb.txt
Normal file
415
Documentation/fb/matroxfb.txt
Normal file
@@ -0,0 +1,415 @@
|
||||
[This file is cloned from VesaFB. Thanks go to Gerd Knorr]
|
||||
|
||||
What is matroxfb?
|
||||
=================
|
||||
|
||||
This is a driver for a graphic framebuffer for Matrox devices on
|
||||
Alpha, Intel and PPC boxes.
|
||||
|
||||
Advantages:
|
||||
|
||||
* It provides a nice large console (128 cols + 48 lines with 1024x768)
|
||||
without using tiny, unreadable fonts.
|
||||
* You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
|
||||
* Most important: boot logo :-)
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* graphic mode is slower than text mode... but you should not notice
|
||||
if you use same resolution as you used in textmode.
|
||||
|
||||
|
||||
How to use it?
|
||||
==============
|
||||
|
||||
Switching modes is done using the video=matroxfb:vesa:... boot parameter
|
||||
or using `fbset' program.
|
||||
|
||||
If you want, for example, enable a resolution of 1280x1024x24bpp you should
|
||||
pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
|
||||
|
||||
You should compile in both vgacon (to boot if you remove you Matrox from
|
||||
box) and matroxfb (for graphics mode). You should not compile-in vesafb
|
||||
unless you have primary display on non-Matrox VBE2.0 device (see
|
||||
Documentation/fb/vesafb.txt for details).
|
||||
|
||||
Currently supported video modes are (through vesa:... interface, PowerMac
|
||||
has [as addon] compatibility code):
|
||||
|
||||
|
||||
[Graphic modes]
|
||||
|
||||
bpp | 640x400 640x480 768x576 800x600 960x720
|
||||
----+--------------------------------------------
|
||||
4 | 0x12 0x102
|
||||
8 | 0x100 0x101 0x180 0x103 0x188
|
||||
15 | 0x110 0x181 0x113 0x189
|
||||
16 | 0x111 0x182 0x114 0x18A
|
||||
24 | 0x1B2 0x184 0x1B5 0x18C
|
||||
32 | 0x112 0x183 0x115 0x18B
|
||||
|
||||
|
||||
[Graphic modes (continued)]
|
||||
|
||||
bpp | 1024x768 1152x864 1280x1024 1408x1056 1600x1200
|
||||
----+------------------------------------------------
|
||||
4 | 0x104 0x106
|
||||
8 | 0x105 0x190 0x107 0x198 0x11C
|
||||
15 | 0x116 0x191 0x119 0x199 0x11D
|
||||
16 | 0x117 0x192 0x11A 0x19A 0x11E
|
||||
24 | 0x1B8 0x194 0x1BB 0x19C 0x1BF
|
||||
32 | 0x118 0x193 0x11B 0x19B
|
||||
|
||||
|
||||
[Text modes]
|
||||
|
||||
text | 640x400 640x480 1056x344 1056x400 1056x480
|
||||
-----+------------------------------------------------
|
||||
8x8 | 0x1C0 0x108 0x10A 0x10B 0x10C
|
||||
8x16 | 2, 3, 7 0x109
|
||||
|
||||
You can enter these number either hexadecimal (leading `0x') or decimal
|
||||
(0x100 = 256). You can also use value + 512 to achieve compatibility
|
||||
with your old number passed to vesafb.
|
||||
|
||||
Non-listed number can be achieved by more complicated command-line, for
|
||||
example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32'.
|
||||
|
||||
|
||||
X11
|
||||
===
|
||||
|
||||
XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
|
||||
architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
|
||||
works fine.
|
||||
|
||||
Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
|
||||
XFree servers have big troubles in multihead configurations (even on first
|
||||
head, not even talking about second). Running XFree86 4.x accelerated mga
|
||||
driver is possible, but you must not enable DRI - if you do, resolution and
|
||||
color depth of your X desktop must match resolution and color depths of your
|
||||
virtual consoles, otherwise X will corrupt accelerator settings.
|
||||
|
||||
|
||||
SVGALib
|
||||
=======
|
||||
|
||||
Driver contains SVGALib compatibility code. It is turned on by choosing textual
|
||||
mode for console. You can do it at boot time by using videomode
|
||||
2,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0' does this work.
|
||||
Unfortunately, after SVGALib application exits, screen contents is corrupted.
|
||||
Switching to another console and back fixes it. I hope that it is SVGALib's
|
||||
problem and not mine, but I'm not sure.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
You can pass kernel command line options to matroxfb with
|
||||
`video=matroxfb:option1,option2:value2,option3' (multiple options should be
|
||||
separated by comma, values are separated from options by `:').
|
||||
Accepted options:
|
||||
|
||||
mem:X - size of memory (X can be in megabytes, kilobytes or bytes)
|
||||
You can only decrease value determined by driver because of
|
||||
it always probe for memory. Default is to use whole detected
|
||||
memory usable for on-screen display (i.e. max. 8 MB).
|
||||
disabled - do not load driver; you can use also `off', but `disabled'
|
||||
is here too.
|
||||
enabled - load driver, if you have `video=matroxfb:disabled' in LILO
|
||||
configuration, you can override it by this (you cannot override
|
||||
`off'). It is default.
|
||||
noaccel - do not use acceleration engine. It does not work on Alphas.
|
||||
accel - use acceleration engine. It is default.
|
||||
nopan - create initial consoles with vyres = yres, thus disabling virtual
|
||||
scrolling.
|
||||
pan - create initial consoles as tall as possible (vyres = memory/vxres).
|
||||
It is default.
|
||||
nopciretry - disable PCI retries. It is needed for some broken chipsets,
|
||||
it is autodetected for intel's 82437. In this case device does
|
||||
not comply to PCI 2.1 specs (it will not guarantee that every
|
||||
transaction terminate with success or retry in 32 PCLK).
|
||||
pciretry - enable PCI retries. It is default, except for intel's 82437.
|
||||
novga - disables VGA I/O ports. It is default if BIOS did not enable device.
|
||||
You should not use this option, some boards then do not restart
|
||||
without power off.
|
||||
vga - preserve state of VGA I/O ports. It is default. Driver does not
|
||||
enable VGA I/O if BIOS did not it (it is not safe to enable it in
|
||||
most cases).
|
||||
nobios - disables BIOS ROM. It is default if BIOS did not enable BIOS itself.
|
||||
You should not use this option, some boards then do not restart
|
||||
without power off.
|
||||
bios - preserve state of BIOS ROM. It is default. Driver does not enable
|
||||
BIOS if BIOS was not enabled before.
|
||||
noinit - tells driver, that devices were already initialized. You should use
|
||||
it if you have G100 and/or if driver cannot detect memory, you see
|
||||
strange pattern on screen and so on. Devices not enabled by BIOS
|
||||
are still initialized. It is default.
|
||||
init - driver initializes every device it knows about.
|
||||
memtype - specifies memory type, implies 'init'. This is valid only for G200
|
||||
and G400 and has following meaning:
|
||||
G200: 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
|
||||
1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
|
||||
2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
|
||||
3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
|
||||
4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
|
||||
5 -> same as above
|
||||
6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
|
||||
7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
|
||||
G400: 0 -> 2x512Kx16 SDRAM, 16/32MB
|
||||
2x512Kx32 SGRAM, 16/32MB
|
||||
1 -> 2x256Kx32 SGRAM, 8/16MB
|
||||
2 -> 4x128Kx32 SGRAM, 8/16MB
|
||||
3 -> 4x512Kx32 SDRAM, 32MB
|
||||
4 -> 4x256Kx32 SGRAM, 16/32MB
|
||||
5 -> 2x1Mx32 SDRAM, 32MB
|
||||
6 -> reserved
|
||||
7 -> reserved
|
||||
You should use sdram or sgram parameter in addition to memtype
|
||||
parameter.
|
||||
nomtrr - disables write combining on frame buffer. This slows down driver but
|
||||
there is reported minor incompatibility between GUS DMA and XFree
|
||||
under high loads if write combining is enabled (sound dropouts).
|
||||
mtrr - enables write combining on frame buffer. It speeds up video accesses
|
||||
much. It is default. You must have MTRR support enabled in kernel
|
||||
and your CPU must have MTRR (f.e. Pentium II have them).
|
||||
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
|
||||
characters.
|
||||
noinv24 - use standard timings. It is the default.
|
||||
inverse - invert colors on screen (for LCD displays)
|
||||
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.
|
||||
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
|
||||
cursor is used (except for text mode).
|
||||
noblink - disables cursor blinking. Cursor in text mode always blinks (hw
|
||||
limitation).
|
||||
blink - enables cursor blinking. It is default.
|
||||
nofastfont - disables fastfont feature. It is default.
|
||||
fastfont:X - enables fastfont feature. X specifies size of memory reserved for
|
||||
font data, it must be >= (fontwidth*fontheight*chars_in_font)/8.
|
||||
It is faster on Gx00 series, but slower on older cards.
|
||||
grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
|
||||
4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
|
||||
displayed through putc/putcs. Direct accesses to framebuffer
|
||||
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.
|
||||
outputs:XYZ - set mapping between CRTC and outputs. Each letter can have value
|
||||
of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter corresponds
|
||||
to primary analog output, second letter to the secondary analog output
|
||||
and third letter to the DVI output. Default setting is 100 for
|
||||
cards below G400 or G400 without DFP, 101 for G400 with DFP, and
|
||||
111 for G450 and G550. You can set mapping only on first card,
|
||||
use matroxset for setting up other devices.
|
||||
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 fbmatroxset
|
||||
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 <vandrove@vc.cvut.cz>
|
||||
61
Documentation/fb/modedb.txt
Normal file
61
Documentation/fb/modedb.txt
Normal file
@@ -0,0 +1,61 @@
|
||||
|
||||
|
||||
modedb default video mode support
|
||||
|
||||
|
||||
Currently all frame buffer device drivers have their own video mode databases,
|
||||
which is a mess and a waste of resources. The main idea of modedb is to have
|
||||
|
||||
- one routine to probe for video modes, which can be used by all frame buffer
|
||||
devices
|
||||
- one generic video mode database with a fair amount of standard videomodes
|
||||
(taken from XFree86)
|
||||
- the possibility to supply your own mode database for graphics hardware that
|
||||
needs non-standard modes, like amifb and Mac frame buffer drivers (which
|
||||
use macmodes.c)
|
||||
|
||||
When a frame buffer device receives a video= option it doesn't know, it should
|
||||
consider that to be a video mode option. If no frame buffer device is specified
|
||||
in a video= option, fbmem considers that to be a global video mode option.
|
||||
|
||||
Valid mode specifiers (mode_option argument):
|
||||
|
||||
<xres>x<yres>[-<bpp>][@<refresh>]
|
||||
<name>[-<bpp>][@<refresh>]
|
||||
|
||||
with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
|
||||
Things between square brackets are optional.
|
||||
|
||||
To find a suitable video mode, you just call
|
||||
|
||||
int __init fb_find_mode(struct fb_var_screeninfo *var,
|
||||
struct fb_info *info, const char *mode_option,
|
||||
const struct fb_videomode *db, unsigned int dbsize,
|
||||
const struct fb_videomode *default_mode,
|
||||
unsigned int default_bpp)
|
||||
|
||||
with db/dbsize your non-standard video mode database, or NULL to use the
|
||||
standard video mode database.
|
||||
|
||||
fb_find_mode() first tries the specified video mode (or any mode that matches,
|
||||
e.g. there can be multiple 640x480 modes, each of them is tried). If that
|
||||
fails, the default mode is tried. If that fails, it walks over all modes.
|
||||
|
||||
To specify a video mode at bootup, use the following boot options:
|
||||
video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
|
||||
|
||||
where <driver> is a name from the table below. Valid default modes can be
|
||||
found in linux/drivers/video/modedb.c. Check your driver's documentation.
|
||||
There may be more modes.
|
||||
|
||||
Drivers that support modedb boot options
|
||||
Boot Name Cards Supported
|
||||
|
||||
amifb - Amiga chipset frame buffer
|
||||
aty128fb - ATI Rage128 / Pro frame buffer
|
||||
atyfb - ATI Mach64 frame buffer
|
||||
tdfxfb - 3D Fx frame buffer
|
||||
tridentfb - Trident (Cyber)blade chipset frame buffer
|
||||
|
||||
BTW, only a few drivers use this at the moment. Others are to follow
|
||||
(feel free to send patches).
|
||||
61
Documentation/fb/pvr2fb.txt
Normal file
61
Documentation/fb/pvr2fb.txt
Normal file
@@ -0,0 +1,61 @@
|
||||
$Id: pvr2fb.txt,v 1.1 2001/05/24 05:09:16 mrbrown Exp $
|
||||
|
||||
What is pvr2fb?
|
||||
===============
|
||||
|
||||
This is a driver for PowerVR 2 based graphics frame buffers, such as the
|
||||
one found in the Dreamcast.
|
||||
|
||||
Advantages:
|
||||
|
||||
* It provides a nice large console (128 cols + 48 lines with 1024x768)
|
||||
without using tiny, unreadable fonts.
|
||||
* You can run XF86_FBDev on top of /dev/fb0
|
||||
* Most important: boot logo :-)
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* Driver is currently limited to the Dreamcast PowerVR 2 implementation
|
||||
at the time of this writing.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
You can pass kernel command line options to pvr2fb with
|
||||
`video=pvr2fb:option1,option2:value2,option3' (multiple options should be
|
||||
separated by comma, values are separated from options by `:').
|
||||
Accepted options:
|
||||
|
||||
font:X - default font to use. All fonts are supported, including the
|
||||
SUN12x22 font which is very nice at high resolutions.
|
||||
|
||||
mode:X - default video mode. The following video modes are supported:
|
||||
640x240-60, 640x480-60.
|
||||
|
||||
Note: the 640x240 mode is currently broken, and should not be
|
||||
used for any reason. It is only mentioned as a reference.
|
||||
|
||||
inverse - invert colors on screen (for LCD displays)
|
||||
|
||||
nomtrr - disables write combining on frame buffer. This slows down driver
|
||||
but there is reported minor incompatibility between GUS DMA and
|
||||
XFree under high loads if write combining is enabled (sound
|
||||
dropouts). MTRR is enabled by default on systems that have it
|
||||
configured and that support it.
|
||||
|
||||
cable:X - cable type. This can be any of the following: vga, rgb, and
|
||||
composite. If none is specified, we guess.
|
||||
|
||||
output:X - output type. This can be any of the following: pal, ntsc, and
|
||||
vga. If none is specified, we guess.
|
||||
|
||||
X11
|
||||
===
|
||||
|
||||
XF86_FBDev should work, in theory. At the time of this writing it is
|
||||
totally untested and may or may not even portray the beginnings of
|
||||
working. If you end up testing this, please let me know!
|
||||
|
||||
--
|
||||
Paul Mundt <lethal@linuxdc.org>
|
||||
|
||||
54
Documentation/fb/pxafb.txt
Normal file
54
Documentation/fb/pxafb.txt
Normal file
@@ -0,0 +1,54 @@
|
||||
Driver for PXA25x LCD controller
|
||||
================================
|
||||
|
||||
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
|
||||
or on the kernel command line
|
||||
video=pxafb:mode:640x480-8,passive
|
||||
|
||||
mode:XRESxYRES[-BPP]
|
||||
XRES == LCCR1_PPL + 1
|
||||
YRES == LLCR2_LPP + 1
|
||||
The resolution of the display in pixels
|
||||
BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
|
||||
|
||||
pixclock:PIXCLOCK
|
||||
Pixel clock in picoseconds
|
||||
|
||||
left:LEFT == LCCR1_BLW + 1
|
||||
right:RIGHT == LCCR1_ELW + 1
|
||||
hsynclen:HSYNC == LCCR1_HSW + 1
|
||||
upper:UPPER == LCCR2_BFW
|
||||
lower:LOWER == LCCR2_EFR
|
||||
vsynclen:VSYNC == LCCR2_VSW + 1
|
||||
Display margins and sync times
|
||||
|
||||
color | mono => LCCR0_CMS
|
||||
umm...
|
||||
|
||||
active | passive => LCCR0_PAS
|
||||
Active (TFT) or Passive (STN) display
|
||||
|
||||
single | dual => LCCR0_SDS
|
||||
Single or dual panel passive display
|
||||
|
||||
4pix | 8pix => LCCR0_DPD
|
||||
4 or 8 pixel monochrome single panel data
|
||||
|
||||
hsync:HSYNC
|
||||
vsync:VSYNC
|
||||
Horizontal and vertical sync. 0 => active low, 1 => active
|
||||
high.
|
||||
|
||||
dpc:DPC
|
||||
Double pixel clock. 1=>true, 0=>false
|
||||
|
||||
outputen:POLARITY
|
||||
Output Enable Polarity. 0 => active low, 1 => active high
|
||||
|
||||
pixclockpol:POLARITY
|
||||
pixel clock polarity
|
||||
0 => falling edge, 1 => rising edge
|
||||
39
Documentation/fb/sa1100fb.txt
Normal file
39
Documentation/fb/sa1100fb.txt
Normal file
@@ -0,0 +1,39 @@
|
||||
[This file is cloned from VesaFB/matroxfb]
|
||||
|
||||
What is sa1100fb?
|
||||
=================
|
||||
|
||||
This is a driver for a graphic framebuffer for the SA-1100 LCD
|
||||
controller.
|
||||
|
||||
Configuration
|
||||
==============
|
||||
|
||||
For most common passive displays, giving the option
|
||||
|
||||
video=sa1100fb:bpp:<value>,lccr0:<value>,lccr1:<value>,lccr2:<value>,lccr3:<value>
|
||||
|
||||
on the kernel command line should be enough to configure the
|
||||
controller. The bits per pixel (bpp) value should be 4, 8, 12, or
|
||||
16. LCCR values are display-specific and should be computed as
|
||||
documented in the SA-1100 Developer's Manual, Section 11.7. Dual-panel
|
||||
displays are supported as long as the SDS bit is set in LCCR0; GPIO<9:2>
|
||||
are used for the lower panel.
|
||||
|
||||
For active displays or displays requiring additional configuration
|
||||
(controlling backlights, powering on the LCD, etc.), the command line
|
||||
options may not be enough to configure the display. Adding sections to
|
||||
sa1100fb_init_fbinfo(), sa1100fb_activate_var(),
|
||||
sa1100fb_disable_lcd_controller(), and sa1100fb_enable_lcd_controller()
|
||||
will probably be necessary.
|
||||
|
||||
Accepted options:
|
||||
|
||||
bpp:<value> Configure for <value> bits per pixel
|
||||
lccr0:<value> Configure LCD control register 0 (11.7.3)
|
||||
lccr1:<value> Configure LCD control register 1 (11.7.4)
|
||||
lccr2:<value> Configure LCD control register 2 (11.7.5)
|
||||
lccr3:<value> Configure LCD control register 3 (11.7.6)
|
||||
|
||||
--
|
||||
Mark Huang <mhuang@livetoy.com>
|
||||
158
Documentation/fb/sisfb.txt
Normal file
158
Documentation/fb/sisfb.txt
Normal file
@@ -0,0 +1,158 @@
|
||||
|
||||
What is sisfb?
|
||||
==============
|
||||
|
||||
sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
|
||||
graphics chips. Supported are:
|
||||
|
||||
- SiS 300 series: SiS 300/305, 540, 630(S), 730(S)
|
||||
- SiS 315 series: SiS 315/H/PRO, 55x, (M)65x, 740, (M)661(F/M)X, (M)741(GX)
|
||||
- SiS 330 series: SiS 330 ("Xabre"), (M)760
|
||||
|
||||
|
||||
Why do I need a framebuffer driver?
|
||||
===================================
|
||||
|
||||
sisfb is eg. useful if you want a high-resolution text console. Besides that,
|
||||
sisfb is required to run DirectFB (which comes with an additional, dedicated
|
||||
driver for the 315 series).
|
||||
|
||||
On the 300 series, sisfb on kernels older than 2.6.3 furthermore plays an
|
||||
important role in connection with DRM/DRI: Sisfb manages the memory heap
|
||||
used by DRM/DRI for 3D texture and other data. This memory management is
|
||||
required for using DRI/DRM.
|
||||
|
||||
Kernels >= around 2.6.3 do not need sisfb any longer for DRI/DRM memory
|
||||
management. The SiS DRM driver has been updated and features a memory manager
|
||||
of its own (which will be used if sisfb is not compiled). So unless you want
|
||||
a graphical console, you don't need sisfb on kernels >=2.6.3.
|
||||
|
||||
Sidenote: Since this seems to be a commonly made mistake: sisfb and vesafb
|
||||
cannot be active at the same time! Do only select one of them in your kernel
|
||||
configuration.
|
||||
|
||||
|
||||
How are parameters passed to sisfb?
|
||||
===================================
|
||||
|
||||
Well, it depends: If compiled statically into the kernel, use lilo's append
|
||||
statement to add the parameters to the kernel command line. Please see lilo's
|
||||
(or GRUB's) documentation for more information. If sisfb is a kernel module,
|
||||
parameters are given with the modprobe (or insmod) command.
|
||||
|
||||
Example for sisfb as part of the static kernel: Add the following line to your
|
||||
lilo.conf:
|
||||
|
||||
append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
|
||||
|
||||
Example for sisfb as a module: Start sisfb by typing
|
||||
|
||||
modprobe sisfb mode=1024x768x16 rate=75 mem=12288
|
||||
|
||||
A common mistake is that folks use a wrong parameter format when using the
|
||||
driver compiled into the kernel. Please note: If compiled into the kernel,
|
||||
the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16
|
||||
(or whatever mode you want to use, alternatively using any other format
|
||||
described above or the vesa keyword instead of mode). If compiled as a module,
|
||||
the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you
|
||||
want to use). Using a "=" for a ":" (and vice versa) is a huge difference!
|
||||
Additionally: If you give more than one argument to the in-kernel sisfb, the
|
||||
arguments are separated with ",". For example:
|
||||
|
||||
video=sisfb:mode:1024x768x16,rate:75,mem:12288
|
||||
|
||||
|
||||
How do I use it?
|
||||
================
|
||||
|
||||
Preface statement: This file only covers very little of the driver's
|
||||
capabilities and features. Please refer to the author's and maintainer's
|
||||
website at http://www.winischhofer.net/linuxsisvga.shtml for more
|
||||
information. Additionally, "modinfo sisfb" gives an overview over all
|
||||
supported options including some explanation.
|
||||
|
||||
The desired display mode can be specified using the keyword "mode" with
|
||||
a parameter in one of the follwing formats:
|
||||
- XxYxDepth or
|
||||
- XxY-Depth or
|
||||
- XxY-Depth@Rate or
|
||||
- XxY
|
||||
- or simply use the VESA mode number in hexadecimal or decimal.
|
||||
|
||||
For example: 1024x768x16, 1024x768-16@75, 1280x1024-16. If no depth is
|
||||
specified, it defaults to 8. If no rate is given, it defaults to 60Hz. Depth 32
|
||||
means 24bit color depth (but 32 bit framebuffer depth, which is not relevant
|
||||
to the user).
|
||||
|
||||
Additionally, sisfb understands the keyword "vesa" followed by a VESA mode
|
||||
number in decimal or hexadecimal. For example: vesa=791 or vesa=0x117. Please
|
||||
use either "mode" or "vesa" but not both.
|
||||
|
||||
Linux 2.4 only: If no mode is given, sisfb defaults to "no mode" (mode=none) if
|
||||
compiled as a module; if sisfb is statically compiled into the kernel, it
|
||||
defaults to 800x600x8 unless CRT2 type is LCD, in which case the LCD's native
|
||||
resolution is used. If you want to switch to a different mode, use the fbset
|
||||
shell command.
|
||||
|
||||
Linux 2.6 only: If no mode is given, sisfb defaults to 800x600x8 unless CRT2
|
||||
type is LCD, in which case it defaults to the LCD's native resolution. If
|
||||
you want to switch to another mode, use the stty shell command.
|
||||
|
||||
You should compile in both vgacon (to boot if you remove you SiS card from
|
||||
your system) and sisfb (for graphics mode). Under Linux 2.6, also "Framebuffer
|
||||
console support" (fbcon) is needed for a graphical console.
|
||||
|
||||
You should *not* compile-in vesafb. And please do not use the "vga=" keyword
|
||||
in lilo's or grub's configuration file; mode selection is done using the
|
||||
"mode" or "vesa" keywords as a parameter. See above and below.
|
||||
|
||||
|
||||
X11
|
||||
===
|
||||
|
||||
If using XFree86 or X.org, it is recommended that you don't use the "fbdev"
|
||||
driver but the dedicated "sis" X driver. The "sis" X driver and sisfb are
|
||||
developed by the same person (Thomas Winischhofer) and cooperate well with
|
||||
each other.
|
||||
|
||||
|
||||
SVGALib
|
||||
=======
|
||||
|
||||
SVGALib, if directly accessing the hardware, never restores the screen
|
||||
correctly, especially on laptops or if the output devices are LCD or TV.
|
||||
Therefore, use the chipset "FBDEV" in SVGALib configuration. This will make
|
||||
SVGALib use the framebuffer device for mode switches and restoration.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
(Some) accepted options:
|
||||
|
||||
off - Disable sisfb. This option is only understood if sisfb is
|
||||
in-kernel, not a module.
|
||||
mem:X - size of memory for the console, rest will be used for DRI/DRM. X
|
||||
is in kilobytes. On 300 series, the default is 4096, 8192 or
|
||||
16384 (each in kilobyte) depending on how much video ram the card
|
||||
has. On 315/330 series, the default is the maximum available ram
|
||||
(since DRI/DRM is not supported for these chipsets).
|
||||
noaccel - do not use 2D acceleration engine. (Default: use acceleration)
|
||||
noypan - disable y-panning and scroll by redrawing the entire screen.
|
||||
This is much slower than y-panning. (Default: use y-panning)
|
||||
vesa:X - selects startup videomode. X is number from 0 to 0x1FF and
|
||||
represents the VESA mode number (can be given in decimal or
|
||||
hexadecimal form, the latter prefixed with "0x").
|
||||
mode:X - selects startup videomode. Please see above for the format of
|
||||
"X".
|
||||
|
||||
Boolean options such as "noaccel" or "noypan" are to be given without a
|
||||
parameter if sisfb is in-kernel (for example "video=sisfb:noypan). If
|
||||
sisfb is a module, these are to be set to 1 (for example "modprobe sisfb
|
||||
noypan=1").
|
||||
|
||||
--
|
||||
Thomas Winischhofer <thomas@winischhofer.net>
|
||||
May 27, 2004
|
||||
|
||||
|
||||
174
Documentation/fb/sstfb.txt
Normal file
174
Documentation/fb/sstfb.txt
Normal file
@@ -0,0 +1,174 @@
|
||||
|
||||
Introduction
|
||||
|
||||
This is a frame buffer device driver for 3dfx' Voodoo Graphics
|
||||
(aka voodoo 1, aka sst1) and Voodoo<6F> (aka Voodoo 2, aka CVG) based
|
||||
video boards. It's highly experimental code, but is guaranteed to work
|
||||
on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d<33>" boards,
|
||||
and with me "between chair and keyboard". Some people tested other
|
||||
combinations and it seems that it works.
|
||||
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
|
||||
(I eat my own dog food)
|
||||
|
||||
Please read the Bug section, and report any success or failure to me
|
||||
(Ghozlane Toumi <gtoumi@laposte.net>).
|
||||
BTW, If you have only one monitor , and you don't feel like playing
|
||||
with the vga passthrou cable, I can only suggest borrowing a screen
|
||||
somewhere...
|
||||
|
||||
|
||||
Installation
|
||||
|
||||
This driver (should) work on ix86, with "late" 2.2.x kernel (tested
|
||||
with x = 19) and "recent" 2.4.x kernel, as a module or compiled in.
|
||||
It has been included in mainstream kernel since the infamous 2.4.10.
|
||||
You can apply the patches found in sstfb/kernel/*-2.{2|4}.x.patch,
|
||||
and copy sstfb.c to linux/drivers/video/, or apply a single patch,
|
||||
sstfb/patch-2.{2|4}.x-sstfb-yymmdd to your linux source tree.
|
||||
|
||||
Then configure your kernel as usual: choose "m" or "y" to 3Dfx Voodoo
|
||||
Graphics in section "console". Compile, install, have fun... and please
|
||||
drop me a report :)
|
||||
|
||||
|
||||
Module Usage
|
||||
|
||||
Warnings.
|
||||
# You should read completely this section before issuing any command.
|
||||
# If you have only one monitor to play with, once you insmod the
|
||||
module, the 3dfx takes control of the output, so you'll have to
|
||||
plug the monitor to the "normal" video board in order to issue
|
||||
the commands, or you can blindly use sst_dbg_vgapass
|
||||
in the tools directory (See Tools). The latest solution is pass the
|
||||
parameter vgapass=1 when insmodding the driver. (See Kernel/Modules
|
||||
Options)
|
||||
|
||||
Module insertion:
|
||||
# insmod sstfb.o
|
||||
you should see some strange output frome the board:
|
||||
a big blue square, a green and a red small squares and a vertical
|
||||
white rectangle. why ? the function's name is self explanatory :
|
||||
"sstfb_test()"...
|
||||
(if you don't have a second monitor, you'll have to plug your monitor
|
||||
directely to the 2D videocard to see what you're typing)
|
||||
# con2fb /dev/fbx /dev/ttyx
|
||||
bind a tty to the new frame buffer. if you already have a frame
|
||||
buffer driver, the voodoo fb will likely be /dev/fb1. if not,
|
||||
the device will be /dev/fb0. You can check this by doing a
|
||||
cat /proc/fb. You can find a copy of con2fb in tools/ directory.
|
||||
if you don't have another fb device, this step is superfluous,
|
||||
as the console subsystem automagicaly binds ttys to the fb.
|
||||
# switch to the virtual console you just mapped. "tadaaa" ...
|
||||
|
||||
Module removal:
|
||||
# con2fb /dev/fbx /dev/ttyx
|
||||
bind the tty to the old frame buffer so the module can be removed.
|
||||
(how does it work with vgacon ? short answer : it doesn't work)
|
||||
# rmmod sstfb
|
||||
|
||||
|
||||
Kernel/Modules Options
|
||||
|
||||
You can pass some otions to sstfb module, and via the kernel command
|
||||
line when the driver is compiled in :
|
||||
for module : insmod sstfb.o option1=value1 option2=value2 ...
|
||||
in kernel : video=sstfb:option1,option2:value2,option3 ...
|
||||
|
||||
sstfb supports the folowing options :
|
||||
|
||||
Module Kernel Description
|
||||
|
||||
vgapass=0 vganopass Enable or disable VGA passthrou cable.
|
||||
vgapass=1 vgapass When enabled, the monitor will get the signal
|
||||
from the VGA board and not from the voodoo.
|
||||
Default: nopass
|
||||
|
||||
mem=x mem:x Force frame buffer memory in MiB
|
||||
allowed values: 0, 1, 2, 4.
|
||||
Default: 0 (= autodetect)
|
||||
|
||||
inverse=1 inverse Supposed to enable inverse console.
|
||||
doesn't work yet...
|
||||
|
||||
clipping=1 clipping Enable or disable clipping.
|
||||
clipping=0 noclipping With clipping enabled, all offscreen
|
||||
reads and writes are disgarded.
|
||||
Default: enable clipping.
|
||||
|
||||
gfxclk=x gfxclk:x Force graphic clock frequency (in MHz).
|
||||
Be carefull with this option, it may be
|
||||
DANGEROUS.
|
||||
Default: auto
|
||||
50Mhz for Voodoo 1,
|
||||
75MHz for Voodoo 2.
|
||||
|
||||
slowpci=1 fastpci Enable or disable fast PCI read/writes.
|
||||
slowpci=1 slowpci Default : fastpci
|
||||
|
||||
dev=x dev:x Attach the driver to device number x.
|
||||
0 is the first compatible board (in
|
||||
lspci order)
|
||||
|
||||
Tools
|
||||
|
||||
These tools are mostly for debugging purposes, but you can
|
||||
find some of these interesting :
|
||||
- con2fb , maps a tty to a fbramebuffer .
|
||||
con2fb /dev/fb1 /dev/tty5
|
||||
- sst_dbg_vgapass , changes vga passthrou. You have to recompile the
|
||||
driver with SST_DEBUG and SST_DEBUG_IOCTL set to 1
|
||||
sst_dbg_vgapass /dev/fb1 1 (enables vga cable)
|
||||
sst_dbg_vgapass /dev/fb1 0 (disables vga cable)
|
||||
- glide_reset , resets the voodoo using glide
|
||||
use this after rmmoding sstfb, if the module refuses to
|
||||
reinsert .
|
||||
|
||||
Bugs
|
||||
|
||||
- DO NOT use glide while the sstfb module is in, you'll most likely
|
||||
hang your computer.
|
||||
- If you see some artefacts (pixels not cleaning and stuff like that),
|
||||
try turning off clipping (clipping=0), and/or using slowpci
|
||||
- the driver don't detect the 4Mb frame buffer voodoos, it seems that
|
||||
the 2 last Mbs wrap around. looking into that .
|
||||
- The driver is 16 bpp only, 24/32 won't work.
|
||||
- The driver is not your_favorite_toy-safe. this includes SMP...
|
||||
[Actually from inspection it seems to be safe - Alan]
|
||||
- when using XFree86 FBdev (X over fbdev) you may see strange color
|
||||
patterns at the border of your windows (the pixels lose the lowest
|
||||
byte -> basicaly the blue component nd some of the green) . I'm unable
|
||||
to reproduce this with XFree86-3.3, but one of the testers has this
|
||||
problem with XFree86-4. apparently recent Xfree86-4.x solve this
|
||||
problem.
|
||||
- I didn't really test changing the palette, so you may find some weird
|
||||
things when playing with that.
|
||||
- Sometimes the driver will not recognise the DAC , and the
|
||||
initialisation will fail. this is specificaly true for
|
||||
voodoo 2 boards , but it should be solved in recent versions. please
|
||||
contact me .
|
||||
- the 24/32 is not likely to work anytime soon , knowing that the
|
||||
hardware does ... unusual thigs in 24/32 bpp
|
||||
- When used with anther video board, current limitations of linux
|
||||
console subsystem can cause some troubles, specificaly, you should
|
||||
disable software scrollback , as it can oops badly ...
|
||||
|
||||
Todo
|
||||
|
||||
- Get rid of the previous paragraph.
|
||||
- Buy more coffee.
|
||||
- test/port to other arch.
|
||||
- try to add panning using tweeks with front and back buffer .
|
||||
- try to implement accel on voodoo2 , this board can actualy do a
|
||||
lot in 2D even if it was sold as a 3D only board ...
|
||||
|
||||
ghoz.
|
||||
|
||||
--
|
||||
Ghozlane Toumi <gtoumi@laposte.net>
|
||||
|
||||
|
||||
$Date: 2002/05/09 20:11:45 $
|
||||
http://sstfb.sourceforge.net/README
|
||||
69
Documentation/fb/tgafb.txt
Normal file
69
Documentation/fb/tgafb.txt
Normal file
@@ -0,0 +1,69 @@
|
||||
$Id: tgafb.txt,v 1.1.2.2 2000/04/04 06:50:18 mato Exp $
|
||||
|
||||
What is tgafb?
|
||||
===============
|
||||
|
||||
This is a driver for DECChip 21030 based graphics framebuffers, a.k.a. TGA
|
||||
cards, which are usually found in older Digital Alpha systems. The
|
||||
following models are supported:
|
||||
|
||||
ZLxP-E1 (8bpp, 2 MB VRAM)
|
||||
ZLxP-E2 (32bpp, 8 MB VRAM)
|
||||
ZLxP-E3 (32bpp, 16 MB VRAM, Zbuffer)
|
||||
|
||||
This version is an almost complete rewrite of the code written by Geert
|
||||
Uytterhoeven, which was based on the original TGA console code written by
|
||||
Jay Estabrook.
|
||||
|
||||
Major new features since Linux 2.0.x:
|
||||
|
||||
* Support for multiple resolutions
|
||||
* Support for fixed-frequency and other oddball monitors
|
||||
(by allowing the video mode to be set at boot time)
|
||||
|
||||
User-visible changes since Linux 2.2.x:
|
||||
|
||||
* Sync-on-green is now handled properly
|
||||
* More useful information is printed on bootup
|
||||
(this helps if people run into problems)
|
||||
|
||||
This driver does not (yet) support the TGA2 family of framebuffers, so the
|
||||
PowerStorm 3D30/4D20 (also known as PBXGB) cards are not supported. These
|
||||
can however be used with the standard VGA Text Console driver.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
You can pass kernel command line options to tgafb with
|
||||
`video=tgafb:option1,option2:value2,option3' (multiple options should be
|
||||
separated by comma, values are separated from options by `:').
|
||||
Accepted options:
|
||||
|
||||
font:X - default font to use. All fonts are supported, including the
|
||||
SUN12x22 font which is very nice at high resolutions.
|
||||
|
||||
mode:X - default video mode. The following video modes are supported:
|
||||
640x480-60, 800x600-56, 640x480-72, 800x600-60, 800x600-72,
|
||||
1024x768-60, 1152x864-60, 1024x768-70, 1024x768-76,
|
||||
1152x864-70, 1280x1024-61, 1024x768-85, 1280x1024-70,
|
||||
1152x864-84, 1280x1024-76, 1280x1024-85
|
||||
|
||||
|
||||
Known Issues
|
||||
============
|
||||
|
||||
The XFree86 FBDev server has been reported not to work, since tgafb doesn't do
|
||||
mmap(). Running the standard XF86_TGA server from XFree86 3.3.x works fine for
|
||||
me, however this server does not do acceleration, which make certain operations
|
||||
quite slow. Support for acceleration is being progressively integrated in
|
||||
XFree86 4.x.
|
||||
|
||||
When running tgafb in resolutions higher than 640x480, on switching VCs from
|
||||
tgafb to XF86_TGA 3.3.x, the entire screen is not re-drawn and must be manually
|
||||
refreshed. This is an X server problem, not a tgafb problem, and is fixed in
|
||||
XFree86 4.0.
|
||||
|
||||
Enjoy!
|
||||
|
||||
Martin Lucina <mato@kotelna.sk>
|
||||
54
Documentation/fb/tridentfb.txt
Normal file
54
Documentation/fb/tridentfb.txt
Normal file
@@ -0,0 +1,54 @@
|
||||
Tridentfb is a framebuffer driver for some Trident chip based cards.
|
||||
|
||||
The following list of chips is thought to be supported although not all are
|
||||
tested:
|
||||
|
||||
those from the Image series with Cyber in their names - accelerated
|
||||
those with Blade in their names (Blade3D,CyberBlade...) - accelerated
|
||||
the newer CyberBladeXP family - nonaccelerated
|
||||
|
||||
Only PCI/AGP based cards are supported, none of the older Tridents.
|
||||
|
||||
How to use it?
|
||||
==============
|
||||
|
||||
When booting you can pass the video parameter.
|
||||
video=tridentfb
|
||||
|
||||
The parameters for tridentfb are concatenated with a ':' as in this example.
|
||||
|
||||
video=tridentfb:800x600,bpp=16,noaccel
|
||||
|
||||
The second level parameters that tridentfb understands are:
|
||||
|
||||
noaccel - turns off acceleration (when it doesn't work for your card)
|
||||
accel - force text acceleration (for boards which by default are noacceled)
|
||||
|
||||
fp - use flat panel related stuff
|
||||
crt - assume monitor is present instead of fp
|
||||
|
||||
center - for flat panels and resolutions smaller than native size center the
|
||||
image, otherwise use
|
||||
stretch
|
||||
|
||||
memsize - integer value in Kb, use if your card's memory size is misdetected.
|
||||
look at the driver output to see what it says when initializing.
|
||||
memdiff - integer value in Kb,should be nonzero if your card reports
|
||||
more memory than it actually has.For instance mine is 192K less than
|
||||
detection says in all three BIOS selectable situations 2M, 4M, 8M.
|
||||
Only use if your video memory is taken from main memory hence of
|
||||
configurable size.Otherwise use memsize.
|
||||
If in some modes which barely fit the memory you see garbage at the bottom
|
||||
this might help by not letting change to that mode anymore.
|
||||
|
||||
nativex - the width in pixels of the flat panel.If you know it (usually 1024
|
||||
800 or 1280) and it is not what the driver seems to detect use it.
|
||||
|
||||
bpp - bits per pixel (8,16 or 32)
|
||||
mode - a mode name like 800x600 (as described in Documentation/fb/modedb.txt)
|
||||
|
||||
Using insane values for the above parameters will probably result in driver
|
||||
misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
|
||||
nativex=93)
|
||||
|
||||
Contact: jani@astechnix.ro
|
||||
167
Documentation/fb/vesafb.txt
Normal file
167
Documentation/fb/vesafb.txt
Normal file
@@ -0,0 +1,167 @@
|
||||
|
||||
What is vesafb?
|
||||
===============
|
||||
|
||||
This is a generic driver for a graphic framebuffer on intel boxes.
|
||||
|
||||
The idea is simple: Turn on graphics mode at boot time with the help
|
||||
of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
|
||||
(and other) ports do.
|
||||
|
||||
This means we decide at boot time whenever we want to run in text or
|
||||
graphics mode. Switching mode later on (in protected mode) is
|
||||
impossible; BIOS calls work in real mode only. VESA BIOS Extensions
|
||||
Version 2.0 are required, because we need a linear frame buffer.
|
||||
|
||||
Advantages:
|
||||
|
||||
* It provides a nice large console (128 cols + 48 lines with 1024x768)
|
||||
without using tiny, unreadable fonts.
|
||||
* You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11
|
||||
support for every VBE 2.0 compliant graphics board).
|
||||
* Most important: boot logo :-)
|
||||
|
||||
Disadvantages:
|
||||
|
||||
* graphic mode is slower than text mode...
|
||||
|
||||
|
||||
How to use it?
|
||||
==============
|
||||
|
||||
Switching modes is done using the vga=... boot parameter. Read
|
||||
Documentation/svga.txt for details.
|
||||
|
||||
You should compile in both vgacon (for text mode) and vesafb (for
|
||||
graphics mode). Which of them takes over the console depends on
|
||||
whenever the specified mode is text or graphics.
|
||||
|
||||
The graphic modes are NOT in the list which you get if you boot with
|
||||
vga=ask and hit return. The mode you wish to use is derived from the
|
||||
VESA mode number. Here are those VESA mode numbers:
|
||||
|
||||
| 640x480 800x600 1024x768 1280x1024
|
||||
----+-------------------------------------
|
||||
256 | 0x101 0x103 0x105 0x107
|
||||
32k | 0x110 0x113 0x116 0x119
|
||||
64k | 0x111 0x114 0x117 0x11A
|
||||
16M | 0x112 0x115 0x118 0x11B
|
||||
|
||||
The video mode number of the Linux kernel is the VESA mode number plus
|
||||
0x200.
|
||||
|
||||
Linux_kernel_mode_number = VESA_mode_number + 0x200
|
||||
|
||||
So the table for the Kernel mode numbers are:
|
||||
|
||||
| 640x480 800x600 1024x768 1280x1024
|
||||
----+-------------------------------------
|
||||
256 | 0x301 0x303 0x305 0x307
|
||||
32k | 0x310 0x313 0x316 0x319
|
||||
64k | 0x311 0x314 0x317 0x31A
|
||||
16M | 0x312 0x315 0x318 0x31B
|
||||
|
||||
To enable one of those modes you have to specify "vga=ask" in the
|
||||
lilo.conf file and rerun LILO. Then you can type in the desired
|
||||
mode at the "vga=ask" prompt. For example if you like to use
|
||||
1024x768x256 colors you have to say "305" at this prompt.
|
||||
|
||||
If this does not work, this might be because your BIOS does not support
|
||||
linear framebuffers or because it does not support this mode at all.
|
||||
Even if your board does, it might be the BIOS which does not. VESA BIOS
|
||||
Extensions v2.0 are required, 1.2 is NOT sufficient. You will get a
|
||||
"bad mode number" message if something goes wrong.
|
||||
|
||||
1. Note: LILO cannot handle hex, for booting directly with
|
||||
"vga=mode-number" you have to transform the numbers to decimal.
|
||||
2. Note: Some newer versions of LILO appear to work with those hex values,
|
||||
if you set the 0x in front of the numbers.
|
||||
|
||||
X11
|
||||
===
|
||||
|
||||
XF68_FBDev should work just fine, but it is non-accelerated. Running
|
||||
another (accelerated) X-Server like XF86_SVGA might or might not work.
|
||||
It depends on X-Server and graphics board.
|
||||
|
||||
The X-Server must restore the video mode correctly, else you end up
|
||||
with a broken console (and vesafb cannot do anything about this).
|
||||
|
||||
|
||||
Refresh rates
|
||||
=============
|
||||
|
||||
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
|
||||
available) and boot linux with loadlin.
|
||||
* use a native driver (matroxfb/atyfb) instead if vesafb. If none
|
||||
is available, write a new one!
|
||||
* VBE 3.0 might work too. I have neither a gfx board with VBE 3.0
|
||||
support nor the specs, so I have not checked this yet.
|
||||
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
The VESA BIOS provides protected mode interface for changing
|
||||
some parameters. vesafb can use it for palette changes and
|
||||
to pan the display. It is turned off by default because it
|
||||
seems not to work with some BIOS versions, but there are options
|
||||
to turn it on.
|
||||
|
||||
You can pass options to vesafb using "video=vesafb:option" on
|
||||
the kernel command line. Multiple options should be separated
|
||||
by comma, like this: "video=vesafb:ypan,invers"
|
||||
|
||||
Accepted options:
|
||||
|
||||
invers no comment...
|
||||
|
||||
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.
|
||||
pro: * scrolling (fullscreen) is fast, because there is
|
||||
no need to copy around data.
|
||||
* You'll get scrollback (the Shift-PgUp thing),
|
||||
the video memory can be used as scrollback buffer
|
||||
kontra: * scrolling only parts of the screen causes some
|
||||
ugly flicker effects (boot logo flickers for
|
||||
example).
|
||||
|
||||
ywrap Same as ypan, but assumes your gfx board can wrap-around
|
||||
the video memory (i.e. starts reading from top if it
|
||||
reaches the end of video memory). Faster than ypan.
|
||||
|
||||
redraw scroll by redrawing the affected part of the screen, this
|
||||
is the safe (and slow) default.
|
||||
|
||||
|
||||
vgapal Use the standard vga registers for palette changes.
|
||||
This is the default.
|
||||
pmipal Use the protected mode interface for palette changes.
|
||||
|
||||
mtrr setup memory type range registers for the vesafb framebuffer.
|
||||
|
||||
vremap:n
|
||||
remap 'n' MiB of video RAM. If 0 or not specified, remap memory
|
||||
according to video mode. (2.5.66 patch/idea by Antonino Daplas
|
||||
reversed to give override possibility (allocate more fb memory
|
||||
than the kernel would) to 2.4 by tmb@iki.fi)
|
||||
|
||||
vtotal:n
|
||||
if the video BIOS of your card incorrectly determines the total
|
||||
amount of video RAM, use this option to override the BIOS (in MiB).
|
||||
|
||||
Have fun!
|
||||
|
||||
Gerd
|
||||
|
||||
--
|
||||
Gerd Knorr <kraxel@goldbach.in-berlin.de>
|
||||
|
||||
Minor (mostly typo) changes
|
||||
by Nico Schmoigl <schmoigl@rumms.uni-mannheim.de>
|
||||
Reference in New Issue
Block a user