Menu
▾
▴
linux-vax-kern-commit
Update of /cvsroot/linux-vax/kernel-2.4/Documentation/fb In directory usw-pr-cvs1:/tmp/cvs-serv7449/fb Modified Files: 00-INDEX clgenfb.txt framebuffer.txt matroxfb.txt tgafb.txt Added Files: README-sstfb.txt pvr2fb.txt Log Message: synch 2.4.15 commit 28 --- NEW FILE --- Introduction This is a frame buffer device driver for 3dfx' Voodoo Graphics (aka voodoo 1, aka sst1) and Voodoo² (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²" 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 incomfortable 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 <gt...@me...>). 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 any 2.2.x kernel (tested with x = 19) and "recent" 2.4.x kernel, as a module or compiled in. 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 option 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=1 vgapass enable or disable VGA passthrou cable vgapass=0 vganopass 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: 1, 2, 4. default detect inverse=1 inverse suposed to enable inverse console. doesn't work ... clipping=1 clipping enable or disable clipping . with clipping=0 noclipping clipping enabled, all offscreen reads and writes are disgarded. default: enable clipping. gfxclk=x gfxclk:x force graphic clock frequency (in MHz) becarefull with this option . default is 50Mhz for voodoo1, 75MHz for voodoo2. Be carefull, this one is dangerous. default=auto slowpci=0 slowpci enable or disable fast PCI read/writes slowpci=1 fastpci 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) - 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 loose 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. I don't know yet if this is the drivers fault or X's (most likely the driver, of course). - 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 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 en voodoo2 , this board can actualy do a lot in 2D even if it was sold as a 3D only board ... ghoz. -- Ghozlane Toumi <gt...@me...> $Date: 2002/04/09 16:55:41 $ http://sstfb.sourceforge.net/README --- NEW FILE --- $Id: pvr2fb.txt,v 1.1 2002/04/09 16:55:41 atp 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=pvr2: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 <le...@li...> Index: 00-INDEX =================================================================== RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/fb/00-INDEX,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- 00-INDEX 14 Jan 2001 20:05:28 -0000 1.1.1.1 +++ 00-INDEX 9 Apr 2002 16:55:41 -0000 1.2 @@ -17,6 +17,8 @@ - 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 Index: clgenfb.txt =================================================================== RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/fb/clgenfb.txt,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- clgenfb.txt 14 Jan 2001 20:05:34 -0000 1.1.1.1 +++ clgenfb.txt 9 Apr 2002 16:55:41 -0000 1.2 @@ -35,11 +35,18 @@ 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 Index: framebuffer.txt =================================================================== RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/fb/framebuffer.txt,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- framebuffer.txt 14 Jan 2001 20:05:31 -0000 1.1.1.1 +++ framebuffer.txt 9 Apr 2002 16:55:41 -0000 1.2 @@ -2,7 +2,7 @@ ----------------------- Maintained by Geert Uytterhoeven <ge...@li...> -Last revised: January 2, 2000 +Last revised: May 10, 2001 0. Introduction @@ -296,7 +296,7 @@ For more specific information about the frame buffer device and its applications, please refer to the Linux-fbdev website: - http://www.linux-fbdev.org/ + http://linux-fbdev.sourceforge.net/ and to the following documentation: @@ -312,13 +312,13 @@ 8. Mailing list --------------- -There's a _development_ mailing list at lin...@vu..., -controlled by majordomo. Send an email with `help' in the message body to -maj...@vu... for subscription information. +There are several frame buffer device related mailing lists at SourceForge: + - lin...@li..., for announcements, + - lin...@li..., for generic user support, + - lin...@li..., for project developers. -The mailing list is archived at - - http://www.mail-archive.com/lin...@vu.../ +Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for +subscription information and archive browsing. 9. Downloading Index: matroxfb.txt =================================================================== RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/fb/matroxfb.txt,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- matroxfb.txt 14 Jan 2001 20:05:34 -0000 1.1.1.1 +++ matroxfb.txt 9 Apr 2002 16:55:41 -0000 1.2 @@ -173,9 +173,9 @@ 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 G200 with SGRAM memory. It has no +sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no effect without `init'. -sdram - tells to driver that you have G200 with SDRAM memory. +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 @@ -216,6 +216,13 @@ secondary (TV) output - if DFP is active, TV output must be inactive and vice versa. DFP always uses same timing as primary (monitor) output. +dfp:X - use settings X for digital flat panel interface. X is number from + 0 to 0xFF, and meaning of each individual bit is described in + G400 manual, in description of DAC register 0x1F. For normal operation + you should set all bits to zero, except lowest bit. This lowest bit + selects who is source of display clocks, whether G400, or panel. + Default value is now read back from hardware - so you should specify + this value only if you are also using `init' parameter. vesa:X - selects startup videomode. X is number from 0 to 0x1FF, see table above for detailed explanation. Default is 640x480x8bpp if driver has 8bpp support. Otherwise first available of 640x350x4bpp, @@ -279,7 +286,9 @@ + 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. - + G200 SGRAM/SDRAM is not autodetected. + + 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. @@ -336,7 +345,7 @@ ACCEL, nofastfont 8x16 12x22 6x11 - Millennium I G200 Millennium I G200 Millennium I G200 + 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 @@ -344,7 +353,7 @@ ACCEL, fastfont 8x16 12x22 6x11 - Millennium I G200 Millennium I G200 Millennium I G200 + 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 @@ -355,6 +364,8 @@ Millennium I G200 TEXT 3.29 1.50 +* Yes, it is slower than Millennium I. + Dualhead G400 ============= @@ -376,7 +387,22 @@ + 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. -* Yes, it is slower than Millennium I. -- Petr Vandrovec <van...@vc...> Index: tgafb.txt =================================================================== RCS file: /cvsroot/linux-vax/kernel-2.4/Documentation/fb/tgafb.txt,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 |
Thanks for helping keep SourceForge clean.
X