aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/fb
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/fb')
-rw-r--r--Documentation/fb/00-INDEX25
-rw-r--r--Documentation/fb/aty128fb.txt72
-rw-r--r--Documentation/fb/cirrusfb.txt97
-rw-r--r--Documentation/fb/framebuffer.txt345
-rw-r--r--Documentation/fb/intel810.txt272
-rw-r--r--Documentation/fb/internals.txt82
-rw-r--r--Documentation/fb/matroxfb.txt415
-rw-r--r--Documentation/fb/modedb.txt61
-rw-r--r--Documentation/fb/pvr2fb.txt61
-rw-r--r--Documentation/fb/pxafb.txt54
-rw-r--r--Documentation/fb/sa1100fb.txt39
-rw-r--r--Documentation/fb/sisfb.txt158
-rw-r--r--Documentation/fb/sstfb.txt174
-rw-r--r--Documentation/fb/tgafb.txt69
-rw-r--r--Documentation/fb/tridentfb.txt54
-rw-r--r--Documentation/fb/vesafb.txt167
16 files changed, 2145 insertions, 0 deletions
diff --git a/Documentation/fb/00-INDEX b/Documentation/fb/00-INDEX
new file mode 100644
index 000000000000..92e89aeef52e
--- /dev/null
+++ b/Documentation/fb/00-INDEX
@@ -0,0 +1,25 @@
1Index of files in Documentation/fb. If you think something about frame
2buffer devices needs an entry here, needs correction or you've written one
3please mail me.
4 Geert Uytterhoeven <geert@linux-m68k.org>
5
600-INDEX
7 - this file
8framebuffer.txt
9 - introduction to frame buffer devices
10internals.txt
11 - quick overview of frame buffer device internals
12modedb.txt
13 - info on the video mode database
14aty128fb.txt
15 - info on the ATI Rage128 frame buffer driver
16clgenfb.txt
17 - info on the Cirrus Logic frame buffer driver
18matroxfb.txt
19 - info on the Matrox frame buffer driver
20pvr2fb.txt
21 - info on the PowerVR 2 frame buffer driver
22tgafb.txt
23 - info on the TGA (DECChip 21030) frame buffer driver
24vesafb.txt
25 - info on the VESA frame buffer device
diff --git a/Documentation/fb/aty128fb.txt b/Documentation/fb/aty128fb.txt
new file mode 100644
index 000000000000..069262fb619d
--- /dev/null
+++ b/Documentation/fb/aty128fb.txt
@@ -0,0 +1,72 @@
1[This file is cloned from VesaFB/matroxfb]
2
3What is aty128fb?
4=================
5
6This is a driver for a graphic framebuffer for ATI Rage128 based devices
7on Intel and PPC boxes.
8
9Advantages:
10
11 * It provides a nice large console (128 cols + 48 lines with 1024x768)
12 without using tiny, unreadable fonts.
13 * You can run XF68_FBDev on top of /dev/fb0
14 * Most important: boot logo :-)
15
16Disadvantages:
17
18 * graphic mode is slower than text mode... but you should not notice
19 if you use same resolution as you used in textmode.
20 * still experimental.
21
22
23How to use it?
24==============
25
26Switching modes is done using the video=aty128fb:<resolution>... modedb
27boot parameter or using `fbset' program.
28
29See Documentation/fb/modedb.txt for more information on modedb
30resolutions.
31
32You should compile in both vgacon (to boot if you remove your Rage128 from
33box) and aty128fb (for graphics mode). You should not compile-in vesafb
34unless you have primary display on non-Rage128 VBE2.0 device (see
35Documentation/fb/vesafb.txt for details).
36
37
38X11
39===
40
41XF68_FBDev should generally work fine, but it is non-accelerated. As of
42this document, 8 and 32bpp works fine. There have been palette issues
43when switching from X to console and back to X. You will have to restart
44X to fix this.
45
46
47Configuration
48=============
49
50You can pass kernel command line options to vesafb with
51`video=aty128fb:option1,option2:value2,option3' (multiple options should
52be separated by comma, values are separated from options by `:').
53Accepted options:
54
55noaccel - do not use acceleration engine. It is default.
56accel - use acceleration engine. Not finished.
57vmode:x - chooses PowerMacintosh video mode <x>. Depreciated.
58cmode:x - chooses PowerMacintosh colour mode <x>. Depreciated.
59<XxX@X> - selects startup videomode. See modedb.txt for detailed
60 explanation. Default is 640x480x8bpp.
61
62
63Limitations
64===========
65
66There are known and unknown bugs, features and misfeatures.
67Currently there are following known bugs:
68 + This driver is still experimental and is not finished. Too many
69 bugs/errata to list here.
70
71--
72Brad Douglas <brad@neruo.com>
diff --git a/Documentation/fb/cirrusfb.txt b/Documentation/fb/cirrusfb.txt
new file mode 100644
index 000000000000..f9436843e998
--- /dev/null
+++ b/Documentation/fb/cirrusfb.txt
@@ -0,0 +1,97 @@
1
2 Framebuffer driver for Cirrus Logic chipsets
3 Copyright 1999 Jeff Garzik <jgarzik@pobox.com>
4
5
6
7{ just a little something to get people going; contributors welcome! }
8
9
10
11Chip families supported:
12 SD64
13 Piccolo
14 Picasso
15 Spectrum
16 Alpine (GD-543x/4x)
17 Picasso4 (GD-5446)
18 GD-5480
19 Laguna (GD-546x)
20
21Bus's supported:
22 PCI
23 Zorro
24
25Architectures supported:
26 i386
27 Alpha
28 PPC (Motorola Powerstack)
29 m68k (Amiga)
30
31
32
33Default video modes
34-------------------
35At the moment, there are two kernel command line arguments supported:
36
37mode:640x480
38mode:800x600
39 or
40mode:1024x768
41
42Full support for startup video modes (modedb) will be integrated soon.
43
44Version 1.9.9.1
45---------------
46* Fix memory detection for 512kB case
47* 800x600 mode
48* Fixed timings
49* Hint for AXP: Use -accel false -vyres -1 when changing resolution
50
51
52Version 1.9.4.4
53---------------
54* Preliminary Laguna support
55* Overhaul color register routines.
56* Associated with the above, console colors are now obtained from a LUT
57 called 'palette' instead of from the VGA registers. This code was
58 modeled after that in atyfb and matroxfb.
59* Code cleanup, add comments.
60* Overhaul SR07 handling.
61* Bug fixes.
62
63
64Version 1.9.4.3
65---------------
66* Correctly set default startup video mode.
67* Do not override ram size setting. Define
68 CLGEN_USE_HARDCODED_RAM_SETTINGS if you _do_ want to override the RAM
69 setting.
70* Compile fixes related to new 2.3.x IORESOURCE_IO[PORT] symbol changes.
71* Use new 2.3.x resource allocation.
72* Some code cleanup.
73
74
75Version 1.9.4.2
76---------------
77* Casting fixes.
78* Assertions no longer cause an oops on purpose.
79* Bug fixes.
80
81
82Version 1.9.4.1
83---------------
84* Add compatibility support. Now requires a 2.1.x, 2.2.x or 2.3.x kernel.
85
86
87Version 1.9.4
88-------------
89* Several enhancements, smaller memory footprint, a few bugfixes.
90* Requires kernel 2.3.14-pre1 or later.
91
92
93Version 1.9.3
94-------------
95* Bundled with kernel 2.3.14-pre1 or later.
96
97
diff --git a/Documentation/fb/framebuffer.txt b/Documentation/fb/framebuffer.txt
new file mode 100644
index 000000000000..610e7801207b
--- /dev/null
+++ b/Documentation/fb/framebuffer.txt
@@ -0,0 +1,345 @@
1 The Frame Buffer Device
2 -----------------------
3
4Maintained by Geert Uytterhoeven <geert@linux-m68k.org>
5Last revised: May 10, 2001
6
7
80. Introduction
9---------------
10
11The frame buffer device provides an abstraction for the graphics hardware. It
12represents the frame buffer of some video hardware and allows application
13software to access the graphics hardware through a well-defined interface, so
14the software doesn't need to know anything about the low-level (hardware
15register) stuff.
16
17The device is accessed through special device nodes, usually located in the
18/dev directory, i.e. /dev/fb*.
19
20
211. User's View of /dev/fb*
22--------------------------
23
24From the user's point of view, the frame buffer device looks just like any
25other device in /dev. It's a character device using major 29; the minor
26specifies the frame buffer number.
27
28By convention, the following device nodes are used (numbers indicate the device
29minor numbers):
30
31 0 = /dev/fb0 First frame buffer
32 1 = /dev/fb1 Second frame buffer
33 ...
34 31 = /dev/fb31 32nd frame buffer
35
36For backwards compatibility, you may want to create the following symbolic
37links:
38
39 /dev/fb0current -> fb0
40 /dev/fb1current -> fb1
41
42and so on...
43
44The frame buffer devices are also `normal' memory devices, this means, you can
45read and write their contents. You can, for example, make a screen snapshot by
46
47 cp /dev/fb0 myfile
48
49There also can be more than one frame buffer at a time, e.g. if you have a
50graphics card in addition to the built-in hardware. The corresponding frame
51buffer devices (/dev/fb0 and /dev/fb1 etc.) work independently.
52
53Application software that uses the frame buffer device (e.g. the X server) will
54use /dev/fb0 by default (older software uses /dev/fb0current). You can specify
55an alternative frame buffer device by setting the environment variable
56$FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash
57users):
58
59 export FRAMEBUFFER=/dev/fb1
60
61or (for csh users):
62
63 setenv FRAMEBUFFER /dev/fb1
64
65After this the X server will use the second frame buffer.
66
67
682. Programmer's View of /dev/fb*
69--------------------------------
70
71As you already know, a frame buffer device is a memory device like /dev/mem and
72it has the same features. You can read it, write it, seek to some location in
73it and mmap() it (the main usage). The difference is just that the memory that
74appears in the special file is not the whole memory, but the frame buffer of
75some video hardware.
76
77/dev/fb* also allows several ioctls on it, by which lots of information about
78the hardware can be queried and set. The color map handling works via ioctls,
79too. Look into <linux/fb.h> for more information on what ioctls exist and on
80which data structures they work. Here's just a brief overview:
81
82 - You can request unchangeable information about the hardware, like name,
83 organization of the screen memory (planes, packed pixels, ...) and address
84 and length of the screen memory.
85
86 - You can request and change variable information about the hardware, like
87 visible and virtual geometry, depth, color map format, timing, and so on.
88 If you try to change that information, the driver maybe will round up some
89 values to meet the hardware's capabilities (or return EINVAL if that isn't
90 possible).
91
92 - You can get and set parts of the color map. Communication is done with 16
93 bits per color part (red, green, blue, transparency) to support all
94 existing hardware. The driver does all the computations needed to apply
95 it to the hardware (round it down to less bits, maybe throw away
96 transparency).
97
98All this hardware abstraction makes the implementation of application programs
99easier and more portable. E.g. the X server works completely on /dev/fb* and
100thus doesn't need to know, for example, how the color registers of the concrete
101hardware are organized. XF68_FBDev is a general X server for bitmapped,
102unaccelerated video hardware. The only thing that has to be built into
103application programs is the screen organization (bitplanes or chunky pixels
104etc.), because it works on the frame buffer image data directly.
105
106For the future it is planned that frame buffer drivers for graphics cards and
107the like can be implemented as kernel modules that are loaded at runtime. Such
108a driver just has to call register_framebuffer() and supply some functions.
109Writing and distributing such drivers independently from the kernel will save
110much trouble...
111
112
1133. Frame Buffer Resolution Maintenance
114--------------------------------------
115
116Frame buffer resolutions are maintained using the utility `fbset'. It can
117change the video mode properties of a frame buffer device. Its main usage is
118to change the current video mode, e.g. during boot up in one of your /etc/rc.*
119or /etc/init.d/* files.
120
121Fbset uses a video mode database stored in a configuration file, so you can
122easily add your own modes and refer to them with a simple identifier.
123
124
1254. The X Server
126---------------
127
128The X server (XF68_FBDev) is the most notable application program for the frame
129buffer device. Starting with XFree86 release 3.2, the X server is part of
130XFree86 and has 2 modes:
131
132 - If the `Display' subsection for the `fbdev' driver in the /etc/XF86Config
133 file contains a
134
135 Modes "default"
136
137 line, the X server will use the scheme discussed above, i.e. it will start
138 up in the resolution determined by /dev/fb0 (or $FRAMEBUFFER, if set). You
139 still have to specify the color depth (using the Depth keyword) and virtual
140 resolution (using the Virtual keyword) though. This is the default for the
141 configuration file supplied with XFree86. It's the most simple
142 configuration, but it has some limitations.
143
144 - Therefore it's also possible to specify resolutions in the /etc/XF86Config
145 file. This allows for on-the-fly resolution switching while retaining the
146 same virtual desktop size. The frame buffer device that's used is still
147 /dev/fb0current (or $FRAMEBUFFER), but the available resolutions are
148 defined by /etc/XF86Config now. The disadvantage is that you have to
149 specify the timings in a different format (but `fbset -x' may help).
150
151To tune a video mode, you can use fbset or xvidtune. Note that xvidtune doesn't
152work 100% with XF68_FBDev: the reported clock values are always incorrect.
153
154
1555. Video Mode Timings
156---------------------
157
158A monitor draws an image on the screen by using an electron beam (3 electron
159beams for color models, 1 electron beam for monochrome monitors). The front of
160the screen is covered by a pattern of colored phosphors (pixels). If a phosphor
161is hit by an electron, it emits a photon and thus becomes visible.
162
163The electron beam draws horizontal lines (scanlines) from left to right, and
164from the top to the bottom of the screen. By modifying the intensity of the
165electron beam, pixels with various colors and intensities can be shown.
166
167After each scanline the electron beam has to move back to the left side of the
168screen and to the next line: this is called the horizontal retrace. After the
169whole screen (frame) was painted, the beam moves back to the upper left corner:
170this is called the vertical retrace. During both the horizontal and vertical
171retrace, the electron beam is turned off (blanked).
172
173The speed at which the electron beam paints the pixels is determined by the
174dotclock in the graphics board. For a dotclock of e.g. 28.37516 MHz (millions
175of cycles per second), each pixel is 35242 ps (picoseconds) long:
176
177 1/(28.37516E6 Hz) = 35.242E-9 s
178
179If the screen resolution is 640x480, it will take
180
181 640*35.242E-9 s = 22.555E-6 s
182
183to paint the 640 (xres) pixels on one scanline. But the horizontal retrace
184also takes time (e.g. 272 `pixels'), so a full scanline takes
185
186 (640+272)*35.242E-9 s = 32.141E-6 s
187
188We'll say that the horizontal scanrate is about 31 kHz:
189
190 1/(32.141E-6 s) = 31.113E3 Hz
191
192A full screen counts 480 (yres) lines, but we have to consider the vertical
193retrace too (e.g. 49 `lines'). So a full screen will take
194
195 (480+49)*32.141E-6 s = 17.002E-3 s
196
197The vertical scanrate is about 59 Hz:
198
199 1/(17.002E-3 s) = 58.815 Hz
200
201This means the screen data is refreshed about 59 times per second. To have a
202stable picture without visible flicker, VESA recommends a vertical scanrate of
203at least 72 Hz. But the perceived flicker is very human dependent: some people
204can use 50 Hz without any trouble, while I'll notice if it's less than 80 Hz.
205
206Since the monitor doesn't know when a new scanline starts, the graphics board
207will supply a synchronization pulse (horizontal sync or hsync) for each
208scanline. Similarly it supplies a synchronization pulse (vertical sync or
209vsync) for each new frame. The position of the image on the screen is
210influenced by the moments at which the synchronization pulses occur.
211
212The following picture summarizes all timings. The horizontal retrace time is
213the sum of the left margin, the right margin and the hsync length, while the
214vertical retrace time is the sum of the upper margin, the lower margin and the
215vsync length.
216
217 +----------+---------------------------------------------+----------+-------+
218 | | ^ | | |
219 | | |upper_margin | | |
220 | | ¥ | | |
221 +----------###############################################----------+-------+
222 | # ^ # | |
223 | # | # | |
224 | # | # | |
225 | # | # | |
226 | left # | # right | hsync |
227 | margin # | xres # margin | len |
228 |<-------->#<---------------+--------------------------->#<-------->|<----->|
229 | # | # | |
230 | # | # | |
231 | # | # | |
232 | # |yres # | |
233 | # | # | |
234 | # | # | |
235 | # | # | |
236 | # | # | |
237 | # | # | |
238 | # | # | |
239 | # | # | |
240 | # | # | |
241 | # ¥ # | |
242 +----------###############################################----------+-------+
243 | | ^ | | |
244 | | |lower_margin | | |
245 | | ¥ | | |
246 +----------+---------------------------------------------+----------+-------+
247 | | ^ | | |
248 | | |vsync_len | | |
249 | | ¥ | | |
250 +----------+---------------------------------------------+----------+-------+
251
252The frame buffer device expects all horizontal timings in number of dotclocks
253(in picoseconds, 1E-12 s), and vertical timings in number of scanlines.
254
255
2566. Converting XFree86 timing values info frame buffer device timings
257--------------------------------------------------------------------
258
259An XFree86 mode line consists of the following fields:
260 "800x600" 50 800 856 976 1040 600 637 643 666
261 < name > DCF HR SH1 SH2 HFL VR SV1 SV2 VFL
262
263The frame buffer device uses the following fields:
264
265 - pixclock: pixel clock in ps (pico seconds)
266 - left_margin: time from sync to picture
267 - right_margin: time from picture to sync
268 - upper_margin: time from sync to picture
269 - lower_margin: time from picture to sync
270 - hsync_len: length of horizontal sync
271 - vsync_len: length of vertical sync
272
2731) Pixelclock:
274 xfree: in MHz
275 fb: in picoseconds (ps)
276
277 pixclock = 1000000 / DCF
278
2792) horizontal timings:
280 left_margin = HFL - SH2
281 right_margin = SH1 - HR
282 hsync_len = SH2 - SH1
283
2843) vertical timings:
285 upper_margin = VFL - SV2
286 lower_margin = SV1 - VR
287 vsync_len = SV2 - SV1
288
289Good examples for VESA timings can be found in the XFree86 source tree,
290under "xc/programs/Xserver/hw/xfree86/doc/modeDB.txt".
291
292
2937. References
294-------------
295
296For more specific information about the frame buffer device and its
297applications, please refer to the Linux-fbdev website:
298
299 http://linux-fbdev.sourceforge.net/
300
301and to the following documentation:
302
303 - The manual pages for fbset: fbset(8), fb.modes(5)
304 - The manual pages for XFree86: XF68_FBDev(1), XF86Config(4/5)
305 - The mighty kernel sources:
306 o linux/drivers/video/
307 o linux/include/linux/fb.h
308 o linux/include/video/
309
310
311
3128. Mailing list
313---------------
314
315There are several frame buffer device related mailing lists at SourceForge:
316 - linux-fbdev-announce@lists.sourceforge.net, for announcements,
317 - linux-fbdev-user@lists.sourceforge.net, for generic user support,
318 - linux-fbdev-devel@lists.sourceforge.net, for project developers.
319
320Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
321subscription information and archive browsing.
322
323
3249. Downloading
325--------------
326
327All necessary files can be found at
328
329 ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/680x0/
330
331and on its mirrors.
332
333The latest version of fbset can be found at
334
335 http://home.tvd.be/cr26864/Linux/fbdev/
336
337
33810. Credits
339----------
340
341This readme was written by Geert Uytterhoeven, partly based on the original
342`X-framebuffer.README' by Roman Hodek and Martin Schaller. Section 6 was
343provided by Frank Neumann.
344
345The frame buffer device abstraction was designed by Martin Schaller.
diff --git a/Documentation/fb/intel810.txt b/Documentation/fb/intel810.txt
new file mode 100644
index 000000000000..fd68b162e4a1
--- /dev/null
+++ b/Documentation/fb/intel810.txt
@@ -0,0 +1,272 @@
1Intel 810/815 Framebuffer driver
2 Tony Daplas <adaplas@pol.net>
3 http://i810fb.sourceforge.net
4
5 March 17, 2002
6
7 First Released: July 2001
8================================================================
9
10A. Introduction
11 This is a framebuffer driver for various Intel 810/815 compatible
12graphics devices. These would include:
13
14 Intel 810
15 Intel 810E
16 Intel 810-DC100
17 Intel 815 Internal graphics only, 100Mhz FSB
18 Intel 815 Internal graphics only
19 Intel 815 Internal graphics and AGP
20
21B. Features
22
23 - Choice of using Discrete Video Timings, VESA Generalized Timing
24 Formula, or a framebuffer specific database to set the video mode
25
26 - Supports a variable range of horizontal and vertical resolution, and
27 vertical refresh rates if the VESA Generalized Timing Formula is
28 enabled.
29
30 - Supports color depths of 8, 16, 24 and 32 bits per pixel
31
32 - Supports pseudocolor, directcolor, or truecolor visuals
33
34 - Full and optimized hardware acceleration at 8, 16 and 24 bpp
35
36 - Robust video state save and restore
37
38 - MTRR support
39
40 - Utilizes user-entered monitor specifications to automatically
41 calculate required video mode parameters.
42
43 - Can concurrently run with xfree86 running with native i810 drivers
44
45 - Hardware Cursor Support
46
47C. List of available options
48
49 a. "video=i810fb"
50 enables the i810 driver
51
52 Recommendation: required
53
54 b. "xres:<value>"
55 select horizontal resolution in pixels
56
57 Recommendation: user preference
58 (default = 640)
59
60 c. "yres:<value>"
61 select vertical resolution in scanlines. If Discrete Video Timings
62 is enabled, this will be ignored and computed as 3*xres/4.
63
64 Recommendation: user preference
65 (default = 480)
66
67 d. "vyres:<value>"
68 select virtual vertical resolution in scanlines. If (0) or none
69 is specified, this will be computed against maximum available memory.
70
71 Recommendation: do not set
72 (default = 480)
73
74 e. "vram:<value>"
75 select amount of system RAM in MB to allocate for the video memory
76
77 Recommendation: 1 - 4 MB.
78 (default = 4)
79
80 f. "bpp:<value>"
81 select desired pixel depth
82
83 Recommendation: 8
84 (default = 8)
85
86 g. "hsync1/hsync2:<value>"
87 select the minimum and maximum Horizontal Sync Frequency of the
88 monitor in KHz. If a using a fixed frequency monitor, hsync1 must
89 be equal to hsync2.
90
91 Recommendation: check monitor manual for correct values
92 default (29/30)
93
94 h. "vsync1/vsync2:<value>"
95 select the minimum and maximum Vertical Sync Frequency of the monitor
96 in Hz. You can also use this option to lock your monitor's refresh
97 rate.
98
99 Recommendation: check monitor manual for correct values
100 (default = 60/60)
101
102 IMPORTANT: If you need to clamp your timings, try to give some
103 leeway for computational errors (over/underflows). Example: if
104 using vsync1/vsync2 = 60/60, make sure hsync1/hsync2 has at least
105 a 1 unit difference, and vice versa.
106
107 i. "voffset:<value>"
108 select at what offset in MB of the logical memory to allocate the
109 framebuffer memory. The intent is to avoid the memory blocks
110 used by standard graphics applications (XFree86). The default
111 offset (16 MB for a 64MB aperture, 8 MB for a 32MB aperture) will
112 avoid XFree86's usage and allows up to 7MB/15MB of framebuffer
113 memory. Depending on your usage, adjust the value up or down,
114 (0 for maximum usage, 31/63 MB for the least amount). Note, an
115 arbitrary setting may conflict with XFree86.
116
117 Recommendation: do not set
118 (default = 8 or 16 MB)
119
120 j. "accel"
121 enable text acceleration. This can be enabled/reenabled anytime
122 by using 'fbset -accel true/false'.
123
124 Recommendation: enable
125 (default = not set)
126
127 k. "mtrr"
128 enable MTRR. This allows data transfers to the framebuffer memory
129 to occur in bursts which can significantly increase performance.
130 Not very helpful with the i810/i815 because of 'shared memory'.
131
132 Recommendation: do not set
133 (default = not set)
134
135 l. "extvga"
136 if specified, secondary/external VGA output will always be enabled.
137 Useful if the BIOS turns off the VGA port when no monitor is attached.
138 The external VGA monitor can then be attached without rebooting.
139
140 Recommendation: do not set
141 (default = not set)
142
143 m. "sync"
144 Forces the hardware engine to do a "sync" or wait for the hardware
145 to finish before starting another instruction. This will produce a
146 more stable setup, but will be slower.
147
148 Recommendation: do not set
149 (default = not set)
150
151 n. "dcolor"
152 Use directcolor visual instead of truecolor for pixel depths greater
153 than 8 bpp. Useful for color tuning, such as gamma control.
154
155 Recommendation: do not set
156 (default = not set)
157
158D. Kernel booting
159
160Separate each option/option-pair by commas (,) and the option from its value
161with a colon (:) as in the following:
162
163video=i810fb:option1,option2:value2
164
165Sample Usage
166------------
167
168In /etc/lilo.conf, add the line:
169
170append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \
171 vsync1:50,vsync2:85,accel,mtrr"
172
173This will initialize the framebuffer to 1024x768 at 8bpp. The framebuffer
174will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate
175will be computed based on the hsync1/hsync2 and vsync1/vsync2 values.
176
177IMPORTANT:
178You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes
179better than 640x480 at 60Hz.
180
181E. Module options
182
183 The module parameters are essentially similar to the kernel
184parameters. The main difference is that you need to include a Boolean value
185(1 for TRUE, and 0 for FALSE) for those options which don't need a value.
186
187Example, to enable MTRR, include "mtrr=1".
188
189Sample Usage
190------------
191
192Using the same setup as described above, load the module like this:
193
194 modprobe i810fb vram=2 xres=1024 bpp=8 hsync1=30 hsync2=55 vsync1=50 \
195 vsync2=85 accel=1 mtrr=1
196
197Or just add the following to /etc/modprobe.conf
198
199 options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \
200 vsync2=85 accel=1 mtrr=1
201
202and just do a
203
204 modprobe i810fb
205
206
207F. Setup
208
209 a. Do your usual method of configuring the kernel.
210
211 make menuconfig/xconfig/config
212
213 b. Under "Code Maturity Options", enable "Prompt for experimental/
214 incomplete code/drivers".
215
216 c. Enable agpgart support for the Intel 810/815 on-board graphics.
217 This is required. The option is under "Character Devices"
218
219 d. Under "Graphics Support", select "Intel 810/815" either statically
220 or as a module. Choose "use VESA GTF for video timings" if you
221 need to maximize the capability of your display. To be on the
222 safe side, you can leave this unselected.
223
224 e. If you want a framebuffer console, enable it under "Console
225 Drivers"
226
227 f. Compile your kernel.
228
229 g. Load the driver as described in section D and E.
230
231 Optional:
232 h. If you are going to run XFree86 with its native drivers, the
233 standard XFree86 4.1.0 and 4.2.0 drivers should work as is.
234 However, there's a bug in the XFree86 i810 drivers. It attempts
235 to use XAA even when switched to the console. This will crash
236 your server. I have a fix at this site:
237
238 http://i810fb.sourceforge.net.
239
240 You can either use the patch, or just replace
241
242 /usr/X11R6/lib/modules/drivers/i810_drv.o
243
244 with the one provided at the website.
245
246 i. Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver
247 patch to see the chipset in action (or inaction :-).
248
249G. Acknowledgment:
250
251 1. Geert Uytterhoeven - his excellent howto and the virtual
252 framebuffer driver code made this possible.
253
254 2. Jeff Hartmann for his agpgart code.
255
256 3. The X developers. Insights were provided just by reading the
257 XFree86 source code.
258
259 4. Intel(c). For this value-oriented chipset driver and for
260 providing documentation.
261
262 5. Matt Sottek. His inputs and ideas helped in making some
263 optimizations possible.
264
265H. Home Page:
266
267 A more complete, and probably updated information is provided at
268http://i810fb.sourceforge.net.
269
270###########################
271Tony
272
diff --git a/Documentation/fb/internals.txt b/Documentation/fb/internals.txt
new file mode 100644
index 000000000000..9b2a2b2f3e57
--- /dev/null
+++ b/Documentation/fb/internals.txt
@@ -0,0 +1,82 @@
1
2This is a first start for some documentation about frame buffer device
3internals.
4
5Geert Uytterhoeven <geert@linux-m68k.org>, 21 July 1998
6James Simmons <jsimmons@user.sf.net>, Nov 26 2002
7
8--------------------------------------------------------------------------------
9
10 *** STRUCTURES USED BY THE FRAME BUFFER DEVICE API ***
11
12The following structures play a role in the game of frame buffer devices. They
13are defined in <linux/fb.h>.
14
151. Outside the kernel (user space)
16
17 - struct fb_fix_screeninfo
18
19 Device independent unchangeable information about a frame buffer device and
20 a specific video mode. This can be obtained using the FBIOGET_FSCREENINFO
21 ioctl.
22
23 - struct fb_var_screeninfo
24
25 Device independent changeable information about a frame buffer device and a
26 specific video mode. This can be obtained using the FBIOGET_VSCREENINFO
27 ioctl, and updated with the FBIOPUT_VSCREENINFO ioctl. If you want to pan
28 the screen only, you can use the FBIOPAN_DISPLAY ioctl.
29
30 - struct fb_cmap
31
32 Device independent colormap information. You can get and set the colormap
33 using the FBIOGETCMAP and FBIOPUTCMAP ioctls.
34
35
362. Inside the kernel
37
38 - struct fb_info
39
40 Generic information, API and low level information about a specific frame
41 buffer device instance (slot number, board address, ...).
42
43 - struct `par'
44
45 Device dependent information that uniquely defines the video mode for this
46 particular piece of hardware.
47
48
49--------------------------------------------------------------------------------
50
51 *** VISUALS USED BY THE FRAME BUFFER DEVICE API ***
52
53
54Monochrome (FB_VISUAL_MONO01 and FB_VISUAL_MONO10)
55-------------------------------------------------
56Each pixel is either black or white.
57
58
59Pseudo color (FB_VISUAL_PSEUDOCOLOR and FB_VISUAL_STATIC_PSEUDOCOLOR)
60---------------------------------------------------------------------
61The whole pixel value is fed through a programmable lookup table that has one
62color (including red, green, and blue intensities) for each possible pixel
63value, and that color is displayed.
64
65
66True color (FB_VISUAL_TRUECOLOR)
67--------------------------------
68The pixel value is broken up into red, green, and blue fields.
69
70
71Direct color (FB_VISUAL_DIRECTCOLOR)
72------------------------------------
73The pixel value is broken up into red, green, and blue fields, each of which
74are looked up in separate red, green, and blue lookup tables.
75
76
77Grayscale displays
78------------------
79Grayscale and static grayscale are special variants of pseudo color and static
80pseudo color, where the red, green and blue components are always equal to
81each other.
82
diff --git a/Documentation/fb/matroxfb.txt b/Documentation/fb/matroxfb.txt
new file mode 100644
index 000000000000..ad7a67707d62
--- /dev/null
+++ b/Documentation/fb/matroxfb.txt
@@ -0,0 +1,415 @@
1[This file is cloned from VesaFB. Thanks go to Gerd Knorr]
2
3What is matroxfb?
4=================
5
6This is a driver for a graphic framebuffer for Matrox devices on
7Alpha, Intel and PPC boxes.
8
9Advantages:
10
11 * It provides a nice large console (128 cols + 48 lines with 1024x768)
12 without using tiny, unreadable fonts.
13 * You can run XF{68,86}_FBDev or XFree86 fbdev driver on top of /dev/fb0
14 * Most important: boot logo :-)
15
16Disadvantages:
17
18 * graphic mode is slower than text mode... but you should not notice
19 if you use same resolution as you used in textmode.
20
21
22How to use it?
23==============
24
25Switching modes is done using the video=matroxfb:vesa:... boot parameter
26or using `fbset' program.
27
28If you want, for example, enable a resolution of 1280x1024x24bpp you should
29pass to the kernel this command line: "video=matroxfb:vesa:0x1BB".
30
31You should compile in both vgacon (to boot if you remove you Matrox from
32box) and matroxfb (for graphics mode). You should not compile-in vesafb
33unless you have primary display on non-Matrox VBE2.0 device (see
34Documentation/fb/vesafb.txt for details).
35
36Currently supported video modes are (through vesa:... interface, PowerMac
37has [as addon] compatibility code):
38
39
40[Graphic modes]
41
42bpp | 640x400 640x480 768x576 800x600 960x720
43----+--------------------------------------------
44 4 | 0x12 0x102
45 8 | 0x100 0x101 0x180 0x103 0x188
46 15 | 0x110 0x181 0x113 0x189
47 16 | 0x111 0x182 0x114 0x18A
48 24 | 0x1B2 0x184 0x1B5 0x18C
49 32 | 0x112 0x183 0x115 0x18B
50
51
52[Graphic modes (continued)]
53
54bpp | 1024x768 1152x864 1280x1024 1408x1056 1600x1200
55----+------------------------------------------------
56 4 | 0x104 0x106
57 8 | 0x105 0x190 0x107 0x198 0x11C
58 15 | 0x116 0x191 0x119 0x199 0x11D
59 16 | 0x117 0x192 0x11A 0x19A 0x11E
60 24 | 0x1B8 0x194 0x1BB 0x19C 0x1BF
61 32 | 0x118 0x193 0x11B 0x19B
62
63
64[Text modes]
65
66text | 640x400 640x480 1056x344 1056x400 1056x480
67-----+------------------------------------------------
68 8x8 | 0x1C0 0x108 0x10A 0x10B 0x10C
698x16 | 2, 3, 7 0x109
70
71You can enter these number either hexadecimal (leading `0x') or decimal
72(0x100 = 256). You can also use value + 512 to achieve compatibility
73with your old number passed to vesafb.
74
75Non-listed number can be achieved by more complicated command-line, for
76example 1600x1200x32bpp can be specified by `video=matroxfb:vesa:0x11C,depth:32'.
77
78
79X11
80===
81
82XF{68,86}_FBDev should work just fine, but it is non-accelerated. On non-intel
83architectures there are some glitches for 24bpp videomodes. 8, 16 and 32bpp
84works fine.
85
86Running another (accelerated) X-Server like XF86_SVGA works too. But (at least)
87XFree servers have big troubles in multihead configurations (even on first
88head, not even talking about second). Running XFree86 4.x accelerated mga
89driver is possible, but you must not enable DRI - if you do, resolution and
90color depth of your X desktop must match resolution and color depths of your
91virtual consoles, otherwise X will corrupt accelerator settings.
92
93
94SVGALib
95=======
96
97Driver contains SVGALib compatibility code. It is turned on by choosing textual
98mode for console. You can do it at boot time by using videomode
992,3,7,0x108-0x10C or 0x1C0. At runtime, `fbset -depth 0' does this work.
100Unfortunately, after SVGALib application exits, screen contents is corrupted.
101Switching to another console and back fixes it. I hope that it is SVGALib's
102problem and not mine, but I'm not sure.
103
104
105Configuration
106=============
107
108You can pass kernel command line options to matroxfb with
109`video=matroxfb:option1,option2:value2,option3' (multiple options should be
110separated by comma, values are separated from options by `:').
111Accepted options:
112
113mem:X - size of memory (X can be in megabytes, kilobytes or bytes)
114 You can only decrease value determined by driver because of
115 it always probe for memory. Default is to use whole detected
116 memory usable for on-screen display (i.e. max. 8 MB).
117disabled - do not load driver; you can use also `off', but `disabled'
118 is here too.
119enabled - load driver, if you have `video=matroxfb:disabled' in LILO
120 configuration, you can override it by this (you cannot override
121 `off'). It is default.
122noaccel - do not use acceleration engine. It does not work on Alphas.
123accel - use acceleration engine. It is default.
124nopan - create initial consoles with vyres = yres, thus disabling virtual
125 scrolling.
126pan - create initial consoles as tall as possible (vyres = memory/vxres).
127 It is default.
128nopciretry - disable PCI retries. It is needed for some broken chipsets,
129 it is autodetected for intel's 82437. In this case device does
130 not comply to PCI 2.1 specs (it will not guarantee that every
131 transaction terminate with success or retry in 32 PCLK).
132pciretry - enable PCI retries. It is default, except for intel's 82437.
133novga - disables VGA I/O ports. It is default if BIOS did not enable device.
134 You should not use this option, some boards then do not restart
135 without power off.
136vga - preserve state of VGA I/O ports. It is default. Driver does not
137 enable VGA I/O if BIOS did not it (it is not safe to enable it in
138 most cases).
139nobios - disables BIOS ROM. It is default if BIOS did not enable BIOS itself.
140 You should not use this option, some boards then do not restart
141 without power off.
142bios - preserve state of BIOS ROM. It is default. Driver does not enable
143 BIOS if BIOS was not enabled before.
144noinit - tells driver, that devices were already initialized. You should use
145 it if you have G100 and/or if driver cannot detect memory, you see
146 strange pattern on screen and so on. Devices not enabled by BIOS
147 are still initialized. It is default.
148init - driver initializes every device it knows about.
149memtype - specifies memory type, implies 'init'. This is valid only for G200
150 and G400 and has following meaning:
151 G200: 0 -> 2x128Kx32 chips, 2MB onboard, probably sgram
152 1 -> 2x128Kx32 chips, 4MB onboard, probably sgram
153 2 -> 2x256Kx32 chips, 4MB onboard, probably sgram
154 3 -> 2x256Kx32 chips, 8MB onboard, probably sgram
155 4 -> 2x512Kx16 chips, 8/16MB onboard, probably sdram only
156 5 -> same as above
157 6 -> 4x128Kx32 chips, 4MB onboard, probably sgram
158 7 -> 4x128Kx32 chips, 8MB onboard, probably sgram
159 G400: 0 -> 2x512Kx16 SDRAM, 16/32MB
160 2x512Kx32 SGRAM, 16/32MB
161 1 -> 2x256Kx32 SGRAM, 8/16MB
162 2 -> 4x128Kx32 SGRAM, 8/16MB
163 3 -> 4x512Kx32 SDRAM, 32MB
164 4 -> 4x256Kx32 SGRAM, 16/32MB
165 5 -> 2x1Mx32 SDRAM, 32MB
166 6 -> reserved
167 7 -> reserved
168 You should use sdram or sgram parameter in addition to memtype
169 parameter.
170nomtrr - disables write combining on frame buffer. This slows down driver but
171 there is reported minor incompatibility between GUS DMA and XFree
172 under high loads if write combining is enabled (sound dropouts).
173mtrr - enables write combining on frame buffer. It speeds up video accesses
174 much. It is default. You must have MTRR support enabled in kernel
175 and your CPU must have MTRR (f.e. Pentium II have them).
176sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no
177 effect without `init'.
178sdram - tells to driver that you have Gxx0 with SDRAM memory.
179 It is a default.
180inv24 - change timings parameters for 24bpp modes on Millenium and
181 Millenium II. Specify this if you see strange color shadows around
182 characters.
183noinv24 - use standard timings. It is the default.
184inverse - invert colors on screen (for LCD displays)
185noinverse - show true colors on screen. It is default.
186dev:X - bind driver to device X. Driver numbers device from 0 up to N,
187 where device 0 is first `known' device found, 1 second and so on.
188 lspci lists devices in this order.
189 Default is `every' known device for driver with multihead support
190 and first working device (usually dev:0) for driver without
191 multihead support.
192nohwcursor - disables hardware cursor (use software cursor instead).
193hwcursor - enables hardware cursor. It is default. If you are using
194 non-accelerated mode (`noaccel' or `fbset -accel false'), software
195 cursor is used (except for text mode).
196noblink - disables cursor blinking. Cursor in text mode always blinks (hw
197 limitation).
198blink - enables cursor blinking. It is default.
199nofastfont - disables fastfont feature. It is default.
200fastfont:X - enables fastfont feature. X specifies size of memory reserved for
201 font data, it must be >= (fontwidth*fontheight*chars_in_font)/8.
202 It is faster on Gx00 series, but slower on older cards.
203grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text,
204 4bpp, 8bpp). In DIRECTCOLOR modes it is limited to characters
205 displayed through putc/putcs. Direct accesses to framebuffer
206 can paint colors.
207nograyscale - disable grayscale summing. It is default.
208cross4MB - enables that pixel line can cross 4MB boundary. It is default for
209 non-Millenium.
210nocross4MB - pixel line must not cross 4MB boundary. It is default for
211 Millenium I or II, because of these devices have hardware
212 limitations which do not allow this. But this option is
213 incompatible with some (if not all yet released) versions of
214 XF86_FBDev.
215dfp - enables digital flat panel interface. This option is incompatible with
216 secondary (TV) output - if DFP is active, TV output must be
217 inactive and vice versa. DFP always uses same timing as primary
218 (monitor) output.
219dfp:X - use settings X for digital flat panel interface. X is number from
220 0 to 0xFF, and meaning of each individual bit is described in
221 G400 manual, in description of DAC register 0x1F. For normal operation
222 you should set all bits to zero, except lowest bit. This lowest bit
223 selects who is source of display clocks, whether G400, or panel.
224 Default value is now read back from hardware - so you should specify
225 this value only if you are also using `init' parameter.
226outputs:XYZ - set mapping between CRTC and outputs. Each letter can have value
227 of 0 (for no CRTC), 1 (CRTC1) or 2 (CRTC2), and first letter corresponds
228 to primary analog output, second letter to the secondary analog output
229 and third letter to the DVI output. Default setting is 100 for
230 cards below G400 or G400 without DFP, 101 for G400 with DFP, and
231 111 for G450 and G550. You can set mapping only on first card,
232 use matroxset for setting up other devices.
233vesa:X - selects startup videomode. X is number from 0 to 0x1FF, see table
234 above for detailed explanation. Default is 640x480x8bpp if driver
235 has 8bpp support. Otherwise first available of 640x350x4bpp,
236 640x480x15bpp, 640x480x24bpp, 640x480x32bpp or 80x25 text
237 (80x25 text is always available).
238
239If you are not satisfied with videomode selected by `vesa' option, you
240can modify it with these options:
241
242xres:X - horizontal resolution, in pixels. Default is derived from `vesa'
243 option.
244yres:X - vertical resolution, in pixel lines. Default is derived from `vesa'
245 option.
246upper:X - top boundary: lines between end of VSYNC pulse and start of first
247 pixel line of picture. Default is derived from `vesa' option.
248lower:X - bottom boundary: lines between end of picture and start of VSYNC
249 pulse. Default is derived from `vesa' option.
250vslen:X - length of VSYNC pulse, in lines. Default is derived from `vesa'
251 option.
252left:X - left boundary: pixels between end of HSYNC pulse and first pixel.
253 Default is derived from `vesa' option.
254right:X - right boundary: pixels between end of picture and start of HSYNC
255 pulse. Default is derived from `vesa' option.
256hslen:X - length of HSYNC pulse, in pixels. Default is derived from `vesa'
257 option.
258pixclock:X - dotclocks, in ps (picoseconds). Default is derived from `vesa'
259 option and from `fh' and `fv' options.
260sync:X - sync. pulse - bit 0 inverts HSYNC polarity, bit 1 VSYNC polarity.
261 If bit 3 (value 0x08) is set, composite sync instead of HSYNC is
262 generated. If bit 5 (value 0x20) is set, sync on green is turned on.
263 Do not forget that if you want sync on green, you also probably
264 want composite sync.
265 Default depends on `vesa'.
266depth:X - Bits per pixel: 0=text, 4,8,15,16,24 or 32. Default depends on
267 `vesa'.
268
269If you know capabilities of your monitor, you can specify some (or all) of
270`maxclk', `fh' and `fv'. In this case, `pixclock' is computed so that
271pixclock <= maxclk, real_fh <= fh and real_fv <= fv.
272
273maxclk:X - maximum dotclock. X can be specified in MHz, kHz or Hz. Default is
274 `don't care'.
275fh:X - maximum horizontal synchronization frequency. X can be specified
276 in kHz or Hz. Default is `don't care'.
277fv:X - maximum vertical frequency. X must be specified in Hz. Default is
278 70 for modes derived from `vesa' with yres <= 400, 60Hz for
279 yres > 400.
280
281
282Limitations
283===========
284
285There are known and unknown bugs, features and misfeatures.
286Currently there are following known bugs:
287 + SVGALib does not restore screen on exit
288 + generic fbcon-cfbX procedures do not work on Alphas. Due to this,
289 `noaccel' (and cfb4 accel) driver does not work on Alpha. So everyone
290 with access to /dev/fb* on Alpha can hang machine (you should restrict
291 access to /dev/fb* - everyone with access to this device can destroy
292 your monitor, believe me...).
293 + 24bpp does not support correctly XF-FBDev on big-endian architectures.
294 + interlaced text mode is not supported; it looks like hardware limitation,
295 but I'm not sure.
296 + Gxx0 SGRAM/SDRAM is not autodetected.
297 + If you are using more than one framebuffer device, you must boot kernel
298 with 'video=scrollback:0'.
299 + maybe more...
300And following misfeatures:
301 + SVGALib does not restore screen on exit.
302 + pixclock for text modes is limited by hardware to
303 83 MHz on G200
304 66 MHz on Millennium I
305 60 MHz on Millennium II
306 Because I have no access to other devices, I do not know specific
307 frequencies for them. So driver does not check this and allows you to
308 set frequency higher that this. It causes sparks, black holes and other
309 pretty effects on screen. Device was not destroyed during tests. :-)
310 + my Millennium G200 oscillator has frequency range from 35 MHz to 380 MHz
311 (and it works with 8bpp on about 320 MHz dotclocks (and changed mclk)).
312 But Matrox says on product sheet that VCO limit is 50-250 MHz, so I believe
313 them (maybe that chip overheats, but it has a very big cooler (G100 has
314 none), so it should work).
315 + special mixed video/graphics videomodes of Mystique and Gx00 - 2G8V16 and
316 G16V16 are not supported
317 + color keying is not supported
318 + feature connector of Mystique and Gx00 is set to VGA mode (it is disabled
319 by BIOS)
320 + DDC (monitor detection) is supported through dualhead driver
321 + some check for input values are not so strict how it should be (you can
322 specify vslen=4000 and so on).
323 + maybe more...
324And following features:
325 + 4bpp is available only on Millennium I and Millennium II. It is hardware
326 limitation.
327 + selection between 1:5:5:5 and 5:6:5 16bpp videomode is done by -rgba
328 option of fbset: "fbset -depth 16 -rgba 5,5,5" selects 1:5:5:5, anything
329 else selects 5:6:5 mode.
330 + text mode uses 6 bit VGA palette instead of 8 bit (one of 262144 colors
331 instead of one of 16M colors). It is due to hardware limitation of
332 Millennium I/II and SVGALib compatibility.
333
334
335Benchmarks
336==========
337It is time to redraw whole screen 1000 times in 1024x768, 60Hz. It is
338time for draw 6144000 characters on screen through /dev/vcsa
339(for 32bpp it is about 3GB of data (exactly 3000 MB); for 8x16 font in
34016 seconds, i.e. 187 MBps).
341Times were obtained from one older version of driver, now they are about 3%
342faster, it is kernel-space only time on P-II/350 MHz, Millennium I in 33 MHz
343PCI slot, G200 in AGP 2x slot. I did not test vgacon.
344
345NOACCEL
346 8x16 12x22
347 Millennium I G200 Millennium I G200
3488bpp 16.42 9.54 12.33 9.13
34916bpp 21.00 15.70 19.11 15.02
35024bpp 36.66 36.66 35.00 35.00
35132bpp 35.00 30.00 33.85 28.66
352
353ACCEL, nofastfont
354 8x16 12x22 6x11
355 Millennium I G200 Millennium I G200 Millennium I G200
3568bpp 7.79 7.24 13.55 7.78 30.00 21.01
35716bpp 9.13 7.78 16.16 7.78 30.00 21.01
35824bpp 14.17 10.72 18.69 10.24 34.99 21.01
35932bpp 16.15 16.16 18.73 13.09 34.99 21.01
360
361ACCEL, fastfont
362 8x16 12x22 6x11
363 Millennium I G200 Millennium I G200 Millennium I G200
3648bpp 8.41 6.01 6.54 4.37 16.00 10.51
36516bpp 9.54 9.12 8.76 6.17 17.52 14.01
36624bpp 15.00 12.36 11.67 10.00 22.01 18.32
36732bpp 16.18 18.29* 12.71 12.74 24.44 21.00
368
369TEXT
370 8x16
371 Millennium I G200
372TEXT 3.29 1.50
373
374* Yes, it is slower than Millennium I.
375
376
377Dualhead G400
378=============
379Driver supports dualhead G400 with some limitations:
380 + secondary head shares videomemory with primary head. It is not problem
381 if you have 32MB of videoram, but if you have only 16MB, you may have
382 to think twice before choosing videomode (for example twice 1880x1440x32bpp
383 is not possible).
384 + due to hardware limitation, secondary head can use only 16 and 32bpp
385 videomodes.
386 + secondary head is not accelerated. There were bad problems with accelerated
387 XFree when secondary head used to use acceleration.
388 + secondary head always powerups in 640x480@60-32 videomode. You have to use
389 fbset to change this mode.
390 + secondary head always powerups in monitor mode. You have to use fbmatroxset
391 to change it to TV mode. Also, you must select at least 525 lines for
392 NTSC output and 625 lines for PAL output.
393 + kernel is not fully multihead ready. So some things are impossible to do.
394 + if you compiled it as module, you must insert i2c-matroxfb, matroxfb_maven
395 and matroxfb_crtc2 into kernel.
396
397
398Dualhead G450
399=============
400Driver supports dualhead G450 with some limitations:
401 + secondary head shares videomemory with primary head. It is not problem
402 if you have 32MB of videoram, but if you have only 16MB, you may have
403 to think twice before choosing videomode.
404 + due to hardware limitation, secondary head can use only 16 and 32bpp
405 videomodes.
406 + secondary head is not accelerated.
407 + secondary head always powerups in 640x480@60-32 videomode. You have to use
408 fbset to change this mode.
409 + TV output is not supported
410 + kernel is not fully multihead ready, so some things are impossible to do.
411 + if you compiled it as module, you must insert matroxfb_g450 and matroxfb_crtc2
412 into kernel.
413
414--
415Petr Vandrovec <vandrove@vc.cvut.cz>
diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt
new file mode 100644
index 000000000000..e04458b319d5
--- /dev/null
+++ b/Documentation/fb/modedb.txt
@@ -0,0 +1,61 @@
1
2
3 modedb default video mode support
4
5
6Currently all frame buffer device drivers have their own video mode databases,
7which is a mess and a waste of resources. The main idea of modedb is to have
8
9 - one routine to probe for video modes, which can be used by all frame buffer
10 devices
11 - one generic video mode database with a fair amount of standard videomodes
12 (taken from XFree86)
13 - the possibility to supply your own mode database for graphics hardware that
14 needs non-standard modes, like amifb and Mac frame buffer drivers (which
15 use macmodes.c)
16
17When a frame buffer device receives a video= option it doesn't know, it should
18consider that to be a video mode option. If no frame buffer device is specified
19in a video= option, fbmem considers that to be a global video mode option.
20
21Valid mode specifiers (mode_option argument):
22
23 <xres>x<yres>[-<bpp>][@<refresh>]
24 <name>[-<bpp>][@<refresh>]
25
26with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string.
27Things between square brackets are optional.
28
29To find a suitable video mode, you just call
30
31int __init fb_find_mode(struct fb_var_screeninfo *var,
32 struct fb_info *info, const char *mode_option,
33 const struct fb_videomode *db, unsigned int dbsize,
34 const struct fb_videomode *default_mode,
35 unsigned int default_bpp)
36
37with db/dbsize your non-standard video mode database, or NULL to use the
38standard video mode database.
39
40fb_find_mode() first tries the specified video mode (or any mode that matches,
41e.g. there can be multiple 640x480 modes, each of them is tried). If that
42fails, the default mode is tried. If that fails, it walks over all modes.
43
44To specify a video mode at bootup, use the following boot options:
45 video=<driver>:<xres>x<yres>[-<bpp>][@refresh]
46
47where <driver> is a name from the table below. Valid default modes can be
48found in linux/drivers/video/modedb.c. Check your driver's documentation.
49There may be more modes.
50
51 Drivers that support modedb boot options
52 Boot Name Cards Supported
53
54 amifb - Amiga chipset frame buffer
55 aty128fb - ATI Rage128 / Pro frame buffer
56 atyfb - ATI Mach64 frame buffer
57 tdfxfb - 3D Fx frame buffer
58 tridentfb - Trident (Cyber)blade chipset frame buffer
59
60BTW, only a few drivers use this at the moment. Others are to follow
61(feel free to send patches).
diff --git a/Documentation/fb/pvr2fb.txt b/Documentation/fb/pvr2fb.txt
new file mode 100644
index 000000000000..2bf6c2321c2d
--- /dev/null
+++ b/Documentation/fb/pvr2fb.txt
@@ -0,0 +1,61 @@
1$Id: pvr2fb.txt,v 1.1 2001/05/24 05:09:16 mrbrown Exp $
2
3What is pvr2fb?
4===============
5
6This is a driver for PowerVR 2 based graphics frame buffers, such as the
7one found in the Dreamcast.
8
9Advantages:
10
11 * It provides a nice large console (128 cols + 48 lines with 1024x768)
12 without using tiny, unreadable fonts.
13 * You can run XF86_FBDev on top of /dev/fb0
14 * Most important: boot logo :-)
15
16Disadvantages:
17
18 * Driver is currently limited to the Dreamcast PowerVR 2 implementation
19 at the time of this writing.
20
21Configuration
22=============
23
24You can pass kernel command line options to pvr2fb with
25`video=pvr2fb:option1,option2:value2,option3' (multiple options should be
26separated by comma, values are separated from options by `:').
27Accepted options:
28
29font:X - default font to use. All fonts are supported, including the
30 SUN12x22 font which is very nice at high resolutions.
31
32mode:X - default video mode. The following video modes are supported:
33 640x240-60, 640x480-60.
34
35 Note: the 640x240 mode is currently broken, and should not be
36 used for any reason. It is only mentioned as a reference.
37
38inverse - invert colors on screen (for LCD displays)
39
40nomtrr - disables write combining on frame buffer. This slows down driver
41 but there is reported minor incompatibility between GUS DMA and
42 XFree under high loads if write combining is enabled (sound
43 dropouts). MTRR is enabled by default on systems that have it
44 configured and that support it.
45
46cable:X - cable type. This can be any of the following: vga, rgb, and
47 composite. If none is specified, we guess.
48
49output:X - output type. This can be any of the following: pal, ntsc, and
50 vga. If none is specified, we guess.
51
52X11
53===
54
55XF86_FBDev should work, in theory. At the time of this writing it is
56totally untested and may or may not even portray the beginnings of
57working. If you end up testing this, please let me know!
58
59--
60Paul Mundt <lethal@linuxdc.org>
61
diff --git a/Documentation/fb/pxafb.txt b/Documentation/fb/pxafb.txt
new file mode 100644
index 000000000000..db9b8500b43b
--- /dev/null
+++ b/Documentation/fb/pxafb.txt
@@ -0,0 +1,54 @@
1Driver for PXA25x LCD controller
2================================
3
4The driver supports the following options, either via
5options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
6
7For example:
8 modprobe pxafb options=mode:640x480-8,passive
9or on the kernel command line
10 video=pxafb:mode:640x480-8,passive
11
12mode:XRESxYRES[-BPP]
13 XRES == LCCR1_PPL + 1
14 YRES == LLCR2_LPP + 1
15 The resolution of the display in pixels
16 BPP == The bit depth. Valid values are 1, 2, 4, 8 and 16.
17
18pixclock:PIXCLOCK
19 Pixel clock in picoseconds
20
21left:LEFT == LCCR1_BLW + 1
22right:RIGHT == LCCR1_ELW + 1
23hsynclen:HSYNC == LCCR1_HSW + 1
24upper:UPPER == LCCR2_BFW
25lower:LOWER == LCCR2_EFR
26vsynclen:VSYNC == LCCR2_VSW + 1
27 Display margins and sync times
28
29color | mono => LCCR0_CMS
30 umm...
31
32active | passive => LCCR0_PAS
33 Active (TFT) or Passive (STN) display
34
35single | dual => LCCR0_SDS
36 Single or dual panel passive display
37
384pix | 8pix => LCCR0_DPD
39 4 or 8 pixel monochrome single panel data
40
41hsync:HSYNC
42vsync:VSYNC
43 Horizontal and vertical sync. 0 => active low, 1 => active
44 high.
45
46dpc:DPC
47 Double pixel clock. 1=>true, 0=>false
48
49outputen:POLARITY
50 Output Enable Polarity. 0 => active low, 1 => active high
51
52pixclockpol:POLARITY
53 pixel clock polarity
54 0 => falling edge, 1 => rising edge
diff --git a/Documentation/fb/sa1100fb.txt b/Documentation/fb/sa1100fb.txt
new file mode 100644
index 000000000000..f1b4220464df
--- /dev/null
+++ b/Documentation/fb/sa1100fb.txt
@@ -0,0 +1,39 @@
1[This file is cloned from VesaFB/matroxfb]
2
3What is sa1100fb?
4=================
5
6This is a driver for a graphic framebuffer for the SA-1100 LCD
7controller.
8
9Configuration
10==============
11
12For most common passive displays, giving the option
13
14video=sa1100fb:bpp:<value>,lccr0:<value>,lccr1:<value>,lccr2:<value>,lccr3:<value>
15
16on the kernel command line should be enough to configure the
17controller. The bits per pixel (bpp) value should be 4, 8, 12, or
1816. LCCR values are display-specific and should be computed as
19documented in the SA-1100 Developer's Manual, Section 11.7. Dual-panel
20displays are supported as long as the SDS bit is set in LCCR0; GPIO<9:2>
21are used for the lower panel.
22
23For active displays or displays requiring additional configuration
24(controlling backlights, powering on the LCD, etc.), the command line
25options may not be enough to configure the display. Adding sections to
26sa1100fb_init_fbinfo(), sa1100fb_activate_var(),
27sa1100fb_disable_lcd_controller(), and sa1100fb_enable_lcd_controller()
28will probably be necessary.
29
30Accepted options:
31
32bpp:<value> Configure for <value> bits per pixel
33lccr0:<value> Configure LCD control register 0 (11.7.3)
34lccr1:<value> Configure LCD control register 1 (11.7.4)
35lccr2:<value> Configure LCD control register 2 (11.7.5)
36lccr3:<value> Configure LCD control register 3 (11.7.6)
37
38--
39Mark Huang <mhuang@livetoy.com>
diff --git a/Documentation/fb/sisfb.txt b/Documentation/fb/sisfb.txt
new file mode 100644
index 000000000000..3b50c517a08d
--- /dev/null
+++ b/Documentation/fb/sisfb.txt
@@ -0,0 +1,158 @@
1
2What is sisfb?
3==============
4
5sisfb is a framebuffer device driver for SiS (Silicon Integrated Systems)
6graphics chips. Supported are:
7
8- SiS 300 series: SiS 300/305, 540, 630(S), 730(S)
9- SiS 315 series: SiS 315/H/PRO, 55x, (M)65x, 740, (M)661(F/M)X, (M)741(GX)
10- SiS 330 series: SiS 330 ("Xabre"), (M)760
11
12
13Why do I need a framebuffer driver?
14===================================
15
16sisfb is eg. useful if you want a high-resolution text console. Besides that,
17sisfb is required to run DirectFB (which comes with an additional, dedicated
18driver for the 315 series).
19
20On the 300 series, sisfb on kernels older than 2.6.3 furthermore plays an
21important role in connection with DRM/DRI: Sisfb manages the memory heap
22used by DRM/DRI for 3D texture and other data. This memory management is
23required for using DRI/DRM.
24
25Kernels >= around 2.6.3 do not need sisfb any longer for DRI/DRM memory
26management. The SiS DRM driver has been updated and features a memory manager
27of its own (which will be used if sisfb is not compiled). So unless you want
28a graphical console, you don't need sisfb on kernels >=2.6.3.
29
30Sidenote: Since this seems to be a commonly made mistake: sisfb and vesafb
31cannot be active at the same time! Do only select one of them in your kernel
32configuration.
33
34
35How are parameters passed to sisfb?
36===================================
37
38Well, it depends: If compiled statically into the kernel, use lilo's append
39statement to add the parameters to the kernel command line. Please see lilo's
40(or GRUB's) documentation for more information. If sisfb is a kernel module,
41parameters are given with the modprobe (or insmod) command.
42
43Example for sisfb as part of the static kernel: Add the following line to your
44lilo.conf:
45
46 append="video=sisfb:mode:1024x768x16,mem:12288,rate:75"
47
48Example for sisfb as a module: Start sisfb by typing
49
50 modprobe sisfb mode=1024x768x16 rate=75 mem=12288
51
52A common mistake is that folks use a wrong parameter format when using the
53driver compiled into the kernel. Please note: If compiled into the kernel,
54the parameter format is video=sisfb:mode:none or video=sisfb:mode:1024x768x16
55(or whatever mode you want to use, alternatively using any other format
56described above or the vesa keyword instead of mode). If compiled as a module,
57the parameter format reads mode=none or mode=1024x768x16 (or whatever mode you
58want to use). Using a "=" for a ":" (and vice versa) is a huge difference!
59Additionally: If you give more than one argument to the in-kernel sisfb, the
60arguments are separated with ",". For example:
61
62 video=sisfb:mode:1024x768x16,rate:75,mem:12288
63
64
65How do I use it?
66================
67
68Preface statement: This file only covers very little of the driver's
69capabilities and features. Please refer to the author's and maintainer's
70website at http://www.winischhofer.net/linuxsisvga.shtml for more
71information. Additionally, "modinfo sisfb" gives an overview over all
72supported options including some explanation.
73
74The desired display mode can be specified using the keyword "mode" with
75a parameter in one of the follwing formats:
76 - XxYxDepth or
77 - XxY-Depth or
78 - XxY-Depth@Rate or
79 - XxY
80 - or simply use the VESA mode number in hexadecimal or decimal.
81
82For example: 1024x768x16, 1024x768-16@75, 1280x1024-16. If no depth is
83specified, it defaults to 8. If no rate is given, it defaults to 60Hz. Depth 32
84means 24bit color depth (but 32 bit framebuffer depth, which is not relevant
85to the user).
86
87Additionally, sisfb understands the keyword "vesa" followed by a VESA mode
88number in decimal or hexadecimal. For example: vesa=791 or vesa=0x117. Please
89use either "mode" or "vesa" but not both.
90
91Linux 2.4 only: If no mode is given, sisfb defaults to "no mode" (mode=none) if
92compiled as a module; if sisfb is statically compiled into the kernel, it
93defaults to 800x600x8 unless CRT2 type is LCD, in which case the LCD's native
94resolution is used. If you want to switch to a different mode, use the fbset
95shell command.
96
97Linux 2.6 only: If no mode is given, sisfb defaults to 800x600x8 unless CRT2
98type is LCD, in which case it defaults to the LCD's native resolution. If
99you want to switch to another mode, use the stty shell command.
100
101You should compile in both vgacon (to boot if you remove you SiS card from
102your system) and sisfb (for graphics mode). Under Linux 2.6, also "Framebuffer
103console support" (fbcon) is needed for a graphical console.
104
105You should *not* compile-in vesafb. And please do not use the "vga=" keyword
106in lilo's or grub's configuration file; mode selection is done using the
107"mode" or "vesa" keywords as a parameter. See above and below.
108
109
110X11
111===
112
113If using XFree86 or X.org, it is recommended that you don't use the "fbdev"
114driver but the dedicated "sis" X driver. The "sis" X driver and sisfb are
115developed by the same person (Thomas Winischhofer) and cooperate well with
116each other.
117
118
119SVGALib
120=======
121
122SVGALib, if directly accessing the hardware, never restores the screen
123correctly, especially on laptops or if the output devices are LCD or TV.
124Therefore, use the chipset "FBDEV" in SVGALib configuration. This will make
125SVGALib use the framebuffer device for mode switches and restoration.
126
127
128Configuration
129=============
130
131(Some) accepted options:
132
133off - Disable sisfb. This option is only understood if sisfb is
134 in-kernel, not a module.
135mem:X - size of memory for the console, rest will be used for DRI/DRM. X
136 is in kilobytes. On 300 series, the default is 4096, 8192 or
137 16384 (each in kilobyte) depending on how much video ram the card
138 has. On 315/330 series, the default is the maximum available ram
139 (since DRI/DRM is not supported for these chipsets).
140noaccel - do not use 2D acceleration engine. (Default: use acceleration)
141noypan - disable y-panning and scroll by redrawing the entire screen.
142 This is much slower than y-panning. (Default: use y-panning)
143vesa:X - selects startup videomode. X is number from 0 to 0x1FF and
144 represents the VESA mode number (can be given in decimal or
145 hexadecimal form, the latter prefixed with "0x").
146mode:X - selects startup videomode. Please see above for the format of
147 "X".
148
149Boolean options such as "noaccel" or "noypan" are to be given without a
150parameter if sisfb is in-kernel (for example "video=sisfb:noypan). If
151sisfb is a module, these are to be set to 1 (for example "modprobe sisfb
152noypan=1").
153
154--
155Thomas Winischhofer <thomas@winischhofer.net>
156May 27, 2004
157
158
diff --git a/Documentation/fb/sstfb.txt b/Documentation/fb/sstfb.txt
new file mode 100644
index 000000000000..628d7ffa8769
--- /dev/null
+++ b/Documentation/fb/sstfb.txt
@@ -0,0 +1,174 @@
1
2Introduction
3
4 This is a frame buffer device driver for 3dfx' Voodoo Graphics
5 (aka voodoo 1, aka sst1) and Voodoo² (aka Voodoo 2, aka CVG) based
6 video boards. It's highly experimental code, but is guaranteed to work
7 on my computer, with my "Maxi Gamer 3D" and "Maxi Gamer 3d²" boards,
8 and with me "between chair and keyboard". Some people tested other
9 combinations and it seems that it works.
10 The main page is located at <http://sstfb.sourceforge.net>, and if
11 you want the latest version, check out the CVS, as the driver is a work
12 in progress, I feel uncomfortable with releasing tarballs of something
13 not completely working...Don't worry, it's still more than useable
14 (I eat my own dog food)
15
16 Please read the Bug section, and report any success or failure to me
17 (Ghozlane Toumi <gtoumi@laposte.net>).
18 BTW, If you have only one monitor , and you don't feel like playing
19 with the vga passthrou cable, I can only suggest borrowing a screen
20 somewhere...
21
22
23Installation
24
25 This driver (should) work on ix86, with "late" 2.2.x kernel (tested
26 with x = 19) and "recent" 2.4.x kernel, as a module or compiled in.
27 It has been included in mainstream kernel since the infamous 2.4.10.
28 You can apply the patches found in sstfb/kernel/*-2.{2|4}.x.patch,
29 and copy sstfb.c to linux/drivers/video/, or apply a single patch,
30 sstfb/patch-2.{2|4}.x-sstfb-yymmdd to your linux source tree.
31
32 Then configure your kernel as usual: choose "m" or "y" to 3Dfx Voodoo
33 Graphics in section "console". Compile, install, have fun... and please
34 drop me a report :)
35
36
37Module Usage
38
39 Warnings.
40 # You should read completely this section before issuing any command.
41 # If you have only one monitor to play with, once you insmod the
42 module, the 3dfx takes control of the output, so you'll have to
43 plug the monitor to the "normal" video board in order to issue
44 the commands, or you can blindly use sst_dbg_vgapass
45 in the tools directory (See Tools). The latest solution is pass the
46 parameter vgapass=1 when insmodding the driver. (See Kernel/Modules
47 Options)
48
49 Module insertion:
50 # insmod sstfb.o
51 you should see some strange output frome the board:
52 a big blue square, a green and a red small squares and a vertical
53 white rectangle. why ? the function's name is self explanatory :
54 "sstfb_test()"...
55 (if you don't have a second monitor, you'll have to plug your monitor
56 directely to the 2D videocard to see what you're typing)
57 # con2fb /dev/fbx /dev/ttyx
58 bind a tty to the new frame buffer. if you already have a frame
59 buffer driver, the voodoo fb will likely be /dev/fb1. if not,
60 the device will be /dev/fb0. You can check this by doing a
61 cat /proc/fb. You can find a copy of con2fb in tools/ directory.
62 if you don't have another fb device, this step is superfluous,
63 as the console subsystem automagicaly binds ttys to the fb.
64 # switch to the virtual console you just mapped. "tadaaa" ...
65
66 Module removal:
67 # con2fb /dev/fbx /dev/ttyx
68 bind the tty to the old frame buffer so the module can be removed.
69 (how does it work with vgacon ? short answer : it doesn't work)
70 # rmmod sstfb
71
72
73Kernel/Modules Options
74
75 You can pass some otions to sstfb module, and via the kernel command
76 line when the driver is compiled in :
77 for module : insmod sstfb.o option1=value1 option2=value2 ...
78 in kernel : video=sstfb:option1,option2:value2,option3 ...
79
80 sstfb supports the folowing options :
81
82Module Kernel Description
83
84vgapass=0 vganopass Enable or disable VGA passthrou cable.
85vgapass=1 vgapass When enabled, the monitor will get the signal
86 from the VGA board and not from the voodoo.
87 Default: nopass
88
89mem=x mem:x Force frame buffer memory in MiB
90 allowed values: 0, 1, 2, 4.
91 Default: 0 (= autodetect)
92
93inverse=1 inverse Supposed to enable inverse console.
94 doesn't work yet...
95
96clipping=1 clipping Enable or disable clipping.
97clipping=0 noclipping With clipping enabled, all offscreen
98 reads and writes are disgarded.
99 Default: enable clipping.
100
101gfxclk=x gfxclk:x Force graphic clock frequency (in MHz).
102 Be carefull with this option, it may be
103 DANGEROUS.
104 Default: auto
105 50Mhz for Voodoo 1,
106 75MHz for Voodoo 2.
107
108slowpci=1 fastpci Enable or disable fast PCI read/writes.
109slowpci=1 slowpci Default : fastpci
110
111dev=x dev:x Attach the driver to device number x.
112 0 is the first compatible board (in
113 lspci order)
114
115Tools
116
117 These tools are mostly for debugging purposes, but you can
118 find some of these interesting :
119 - con2fb , maps a tty to a fbramebuffer .
120 con2fb /dev/fb1 /dev/tty5
121 - sst_dbg_vgapass , changes vga passthrou. You have to recompile the
122 driver with SST_DEBUG and SST_DEBUG_IOCTL set to 1
123 sst_dbg_vgapass /dev/fb1 1 (enables vga cable)
124 sst_dbg_vgapass /dev/fb1 0 (disables vga cable)
125 - glide_reset , resets the voodoo using glide
126 use this after rmmoding sstfb, if the module refuses to
127 reinsert .
128
129Bugs
130
131 - DO NOT use glide while the sstfb module is in, you'll most likely
132 hang your computer.
133 - If you see some artefacts (pixels not cleaning and stuff like that),
134 try turning off clipping (clipping=0), and/or using slowpci
135 - the driver don't detect the 4Mb frame buffer voodoos, it seems that
136 the 2 last Mbs wrap around. looking into that .
137 - The driver is 16 bpp only, 24/32 won't work.
138 - The driver is not your_favorite_toy-safe. this includes SMP...
139 [Actually from inspection it seems to be safe - Alan]
140 - when using XFree86 FBdev (X over fbdev) you may see strange color
141 patterns at the border of your windows (the pixels lose the lowest
142 byte -> basicaly the blue component nd some of the green) . I'm unable
143 to reproduce this with XFree86-3.3, but one of the testers has this
144 problem with XFree86-4. apparently recent Xfree86-4.x solve this
145 problem.
146 - I didn't really test changing the palette, so you may find some weird
147 things when playing with that.
148 - Sometimes the driver will not recognise the DAC , and the
149 initialisation will fail. this is specificaly true for
150 voodoo 2 boards , but it should be solved in recent versions. please
151 contact me .
152 - the 24/32 is not likely to work anytime soon , knowing that the
153 hardware does ... unusual thigs in 24/32 bpp
154 - When used with anther video board, current limitations of linux
155 console subsystem can cause some troubles, specificaly, you should
156 disable software scrollback , as it can oops badly ...
157
158Todo
159
160 - Get rid of the previous paragraph.
161 - Buy more coffee.
162 - test/port to other arch.
163 - try to add panning using tweeks with front and back buffer .
164 - try to implement accel on voodoo2 , this board can actualy do a
165 lot in 2D even if it was sold as a 3D only board ...
166
167ghoz.
168
169--
170Ghozlane Toumi <gtoumi@laposte.net>
171
172
173$Date: 2002/05/09 20:11:45 $
174http://sstfb.sourceforge.net/README
diff --git a/Documentation/fb/tgafb.txt b/Documentation/fb/tgafb.txt
new file mode 100644
index 000000000000..250083ada8fb
--- /dev/null
+++ b/Documentation/fb/tgafb.txt
@@ -0,0 +1,69 @@
1$Id: tgafb.txt,v 1.1.2.2 2000/04/04 06:50:18 mato Exp $
2
3What is tgafb?
4===============
5
6This is a driver for DECChip 21030 based graphics framebuffers, a.k.a. TGA
7cards, which are usually found in older Digital Alpha systems. The
8following models are supported:
9
10ZLxP-E1 (8bpp, 2 MB VRAM)
11ZLxP-E2 (32bpp, 8 MB VRAM)
12ZLxP-E3 (32bpp, 16 MB VRAM, Zbuffer)
13
14This version is an almost complete rewrite of the code written by Geert
15Uytterhoeven, which was based on the original TGA console code written by
16Jay Estabrook.
17
18Major new features since Linux 2.0.x:
19
20 * Support for multiple resolutions
21 * Support for fixed-frequency and other oddball monitors
22 (by allowing the video mode to be set at boot time)
23
24User-visible changes since Linux 2.2.x:
25
26 * Sync-on-green is now handled properly
27 * More useful information is printed on bootup
28 (this helps if people run into problems)
29
30This driver does not (yet) support the TGA2 family of framebuffers, so the
31PowerStorm 3D30/4D20 (also known as PBXGB) cards are not supported. These
32can however be used with the standard VGA Text Console driver.
33
34
35Configuration
36=============
37
38You can pass kernel command line options to tgafb with
39`video=tgafb:option1,option2:value2,option3' (multiple options should be
40separated by comma, values are separated from options by `:').
41Accepted options:
42
43font:X - default font to use. All fonts are supported, including the
44 SUN12x22 font which is very nice at high resolutions.
45
46mode:X - default video mode. The following video modes are supported:
47 640x480-60, 800x600-56, 640x480-72, 800x600-60, 800x600-72,
48 1024x768-60, 1152x864-60, 1024x768-70, 1024x768-76,
49 1152x864-70, 1280x1024-61, 1024x768-85, 1280x1024-70,
50 1152x864-84, 1280x1024-76, 1280x1024-85
51
52
53Known Issues
54============
55
56The XFree86 FBDev server has been reported not to work, since tgafb doesn't do
57mmap(). Running the standard XF86_TGA server from XFree86 3.3.x works fine for
58me, however this server does not do acceleration, which make certain operations
59quite slow. Support for acceleration is being progressively integrated in
60XFree86 4.x.
61
62When running tgafb in resolutions higher than 640x480, on switching VCs from
63tgafb to XF86_TGA 3.3.x, the entire screen is not re-drawn and must be manually
64refreshed. This is an X server problem, not a tgafb problem, and is fixed in
65XFree86 4.0.
66
67Enjoy!
68
69Martin Lucina <mato@kotelna.sk>
diff --git a/Documentation/fb/tridentfb.txt b/Documentation/fb/tridentfb.txt
new file mode 100644
index 000000000000..8a6c8a43e6a3
--- /dev/null
+++ b/Documentation/fb/tridentfb.txt
@@ -0,0 +1,54 @@
1Tridentfb is a framebuffer driver for some Trident chip based cards.
2
3The following list of chips is thought to be supported although not all are
4tested:
5
6those from the Image series with Cyber in their names - accelerated
7those with Blade in their names (Blade3D,CyberBlade...) - accelerated
8the newer CyberBladeXP family - nonaccelerated
9
10Only PCI/AGP based cards are supported, none of the older Tridents.
11
12How to use it?
13==============
14
15When booting you can pass the video parameter.
16video=tridentfb
17
18The parameters for tridentfb are concatenated with a ':' as in this example.
19
20video=tridentfb:800x600,bpp=16,noaccel
21
22The second level parameters that tridentfb understands are:
23
24noaccel - turns off acceleration (when it doesn't work for your card)
25accel - force text acceleration (for boards which by default are noacceled)
26
27fp - use flat panel related stuff
28crt - assume monitor is present instead of fp
29
30center - for flat panels and resolutions smaller than native size center the
31 image, otherwise use
32stretch
33
34memsize - integer value in Kb, use if your card's memory size is misdetected.
35 look at the driver output to see what it says when initializing.
36memdiff - integer value in Kb,should be nonzero if your card reports
37 more memory than it actually has.For instance mine is 192K less than
38 detection says in all three BIOS selectable situations 2M, 4M, 8M.
39 Only use if your video memory is taken from main memory hence of
40 configurable size.Otherwise use memsize.
41 If in some modes which barely fit the memory you see garbage at the bottom
42 this might help by not letting change to that mode anymore.
43
44nativex - the width in pixels of the flat panel.If you know it (usually 1024
45 800 or 1280) and it is not what the driver seems to detect use it.
46
47bpp - bits per pixel (8,16 or 32)
48mode - a mode name like 800x600 (as described in Documentation/fb/modedb.txt)
49
50Using insane values for the above parameters will probably result in driver
51misbehaviour so take care(for instance memsize=12345678 or memdiff=23784 or
52nativex=93)
53
54Contact: jani@astechnix.ro
diff --git a/Documentation/fb/vesafb.txt b/Documentation/fb/vesafb.txt
new file mode 100644
index 000000000000..814e2f56a6ad
--- /dev/null
+++ b/Documentation/fb/vesafb.txt
@@ -0,0 +1,167 @@
1
2What is vesafb?
3===============
4
5This is a generic driver for a graphic framebuffer on intel boxes.
6
7The idea is simple: Turn on graphics mode at boot time with the help
8of the BIOS, and use this as framebuffer device /dev/fb0, like the m68k
9(and other) ports do.
10
11This means we decide at boot time whenever we want to run in text or
12graphics mode. Switching mode later on (in protected mode) is
13impossible; BIOS calls work in real mode only. VESA BIOS Extensions
14Version 2.0 are required, because we need a linear frame buffer.
15
16Advantages:
17
18 * It provides a nice large console (128 cols + 48 lines with 1024x768)
19 without using tiny, unreadable fonts.
20 * You can run XF68_FBDev on top of /dev/fb0 (=> non-accelerated X11
21 support for every VBE 2.0 compliant graphics board).
22 * Most important: boot logo :-)
23
24Disadvantages:
25
26 * graphic mode is slower than text mode...
27
28
29How to use it?
30==============
31
32Switching modes is done using the vga=... boot parameter. Read
33Documentation/svga.txt for details.
34
35You should compile in both vgacon (for text mode) and vesafb (for
36graphics mode). Which of them takes over the console depends on
37whenever the specified mode is text or graphics.
38
39The graphic modes are NOT in the list which you get if you boot with
40vga=ask and hit return. The mode you wish to use is derived from the
41VESA mode number. Here are those VESA mode numbers:
42
43 | 640x480 800x600 1024x768 1280x1024
44----+-------------------------------------
45256 | 0x101 0x103 0x105 0x107
4632k | 0x110 0x113 0x116 0x119
4764k | 0x111 0x114 0x117 0x11A
4816M | 0x112 0x115 0x118 0x11B
49
50The video mode number of the Linux kernel is the VESA mode number plus
510x200.
52
53 Linux_kernel_mode_number = VESA_mode_number + 0x200
54
55So the table for the Kernel mode numbers are:
56
57 | 640x480 800x600 1024x768 1280x1024
58----+-------------------------------------
59256 | 0x301 0x303 0x305 0x307
6032k | 0x310 0x313 0x316 0x319
6164k | 0x311 0x314 0x317 0x31A
6216M | 0x312 0x315 0x318 0x31B
63
64To enable one of those modes you have to specify "vga=ask" in the
65lilo.conf file and rerun LILO. Then you can type in the desired
66mode at the "vga=ask" prompt. For example if you like to use
671024x768x256 colors you have to say "305" at this prompt.
68
69If this does not work, this might be because your BIOS does not support
70linear framebuffers or because it does not support this mode at all.
71Even if your board does, it might be the BIOS which does not. VESA BIOS
72Extensions v2.0 are required, 1.2 is NOT sufficient. You will get a
73"bad mode number" message if something goes wrong.
74
751. Note: LILO cannot handle hex, for booting directly with
76 "vga=mode-number" you have to transform the numbers to decimal.
772. Note: Some newer versions of LILO appear to work with those hex values,
78 if you set the 0x in front of the numbers.
79
80X11
81===
82
83XF68_FBDev should work just fine, but it is non-accelerated. Running
84another (accelerated) X-Server like XF86_SVGA might or might not work.
85It depends on X-Server and graphics board.
86
87The X-Server must restore the video mode correctly, else you end up
88with a broken console (and vesafb cannot do anything about this).
89
90
91Refresh rates
92=============
93
94There is no way to change the vesafb video mode and/or timings after
95booting linux. If you are not happy with the 60 Hz refresh rate, you
96have these options:
97
98 * configure and load the DOS-Tools for your the graphics board (if
99 available) and boot linux with loadlin.
100 * use a native driver (matroxfb/atyfb) instead if vesafb. If none
101 is available, write a new one!
102 * VBE 3.0 might work too. I have neither a gfx board with VBE 3.0
103 support nor the specs, so I have not checked this yet.
104
105
106Configuration
107=============
108
109The VESA BIOS provides protected mode interface for changing
110some parameters. vesafb can use it for palette changes and
111to pan the display. It is turned off by default because it
112seems not to work with some BIOS versions, but there are options
113to turn it on.
114
115You can pass options to vesafb using "video=vesafb:option" on
116the kernel command line. Multiple options should be separated
117by comma, like this: "video=vesafb:ypan,invers"
118
119Accepted options:
120
121invers no comment...
122
123ypan enable display panning using the VESA protected mode
124 interface. The visible screen is just a window of the
125 video memory, console scrolling is done by changing the
126 start of the window.
127 pro: * scrolling (fullscreen) is fast, because there is
128 no need to copy around data.
129 * You'll get scrollback (the Shift-PgUp thing),
130 the video memory can be used as scrollback buffer
131 kontra: * scrolling only parts of the screen causes some
132 ugly flicker effects (boot logo flickers for
133 example).
134
135ywrap Same as ypan, but assumes your gfx board can wrap-around
136 the video memory (i.e. starts reading from top if it
137 reaches the end of video memory). Faster than ypan.
138
139redraw scroll by redrawing the affected part of the screen, this
140 is the safe (and slow) default.
141
142
143vgapal Use the standard vga registers for palette changes.
144 This is the default.
145pmipal Use the protected mode interface for palette changes.
146
147mtrr setup memory type range registers for the vesafb framebuffer.
148
149vremap:n
150 remap 'n' MiB of video RAM. If 0 or not specified, remap memory
151 according to video mode. (2.5.66 patch/idea by Antonino Daplas
152 reversed to give override possibility (allocate more fb memory
153 than the kernel would) to 2.4 by tmb@iki.fi)
154
155vtotal:n
156 if the video BIOS of your card incorrectly determines the total
157 amount of video RAM, use this option to override the BIOS (in MiB).
158
159Have fun!
160
161 Gerd
162
163--
164Gerd Knorr <kraxel@goldbach.in-berlin.de>
165
166Minor (mostly typo) changes
167by Nico Schmoigl <schmoigl@rumms.uni-mannheim.de>
generated by cgit v1.2.2 (git 2.25.0) at 2024-11-19 04:18:17 -0500