Unidentified subject!
In reply to Andreas Beck <[EMAIL PROTECTED]> >If not, someone should finally attack a generic stretching/rotating >target ... or a target that just fills the rest of the visual with a black border, with the `actual' visual at the center. such a target is actually essential for lcd screens, and it should be extremely easy to implement. what is hard to digest is the impossibility (or tricky possibility) of running some program because it wants *less* than what your system can offer... -- Cesar Augusto Rorato Crusius__o __o __o __o __o Stanford University _`\<,_`\<,_`\<,_`\<,_`\<, e-mail:[EMAIL PROTECTED](_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_) www.stanford.edu/~crusius o _ _ _ __o __o __o __o /\_ _ \\o (_)\__/o (_) _`\<,_`\<,_`\<,_`\<,_>(_) (_)/<_\_| \ _|/' \/ (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)(_) (_)(_)' _\o_ He who sacrifices functionality for ease of use Loses both and deserves neither
Unidentified subject!
Hello,
I just started trying to do some basic graphics programming with ggi. I
downloaded the latest snapshot, installed it and wrote a small program
based on the "dummies guide" available at www.ggi-project.org. It
compiles/links without any errors, but it refuses to work correctly. I am
under Linux 2.2.16, Slackware 7.1.
After I invoke the following program, the screen isn't cleared (i.e., the console
remains
visible) - it looks like this (if I run "clear" at the command line before
invoking the program):
manel@rolling:~/programas$ pixel
LibGG: unable to open lib: /usr/local/lib/ggi/default/fbdev/kgi/genkgi.so:
cannot open shared object file: No such file or directory
Then I press "Enter" and the prompt returns... When I ran some of the
available demo programs, I also got this error message, but the app worked
(I only saw the message *after* I quit the program and the console was
restored). I looked at the source for some demos and they seem to use pretty
much the same method... but I must be missing something. :)
Here is the source; I am compiling it with
$ gcc -o pixel pixel.c -lggi -lm
Thank you for any help,
Manuel
#include
#include
ggi_visual_t vis;
ggi_pixel white;
ggi_color map;
int main()
{
if (ggiInit())
{
printf("\nErro: ggiInit() falhou!\n");
return 1;
}
if ((vis=ggiOpen(NULL))==NULL)
{
ggiExit();
printf("\nErro: ggiOpen() falhou!\n");
return 2;
}
if (ggiSetSimpleMode(vis,GGI_AUTO,GGI_AUTO,GGI_AUTO,GT_AUTO)!=0)
{
ggiPanic("\nErro: impossÃvel definir modo a utilizar\n");
}
map.r=0x;
map.g=0x;
map.b=0x;
white=ggiMapColor(vis,&map);
ggiPutPixel(vis,0,0,white);
ggiClose(vis);
ggiExit();
getchar();
return 0;
}
keyboard interfaces & crashes (was Re: Unidentified subject!)
> > It does crash my system/keyboard when i try to quit the test pattern, >but > > that's probably cuase i'm using a old library. > >That's strange. Please enable Magic SysRq for debugging purposes and then >help us to track that one down. I'll do that right after i see if it still hapens with a recent version of libggi. > > A employee has just told me that his computer shop has instructed him to > > ram his ps/2 keyboard into the serial port on his windows 98 machine. > >Umm - how would that work ? Maybe with a ps2/serial adapter, like the ones >used for mice ... The PS/2 port is basically a clocked serial port, so it >might be possible, but I'd rather use the two PS/2 ports for keyboards and >the serial ones for mice. > >CU, Andy Agreed. I personally will probably buy some USB keyboards and mice. Your method will work up to two keyboards. your third keyboard would have to be serail "com3", and your third mouse could be com4. (and yes he used a adapter to plug the keybaord into the serial port.) I just thought i'd toss out the idea for any deverlopers, who want to set up a large keyboard array, but are too cheap to buy USB keybards :) later Corey __ Get Your Private, Free Email at http://www.hotmail.com
Re: Unidentified subject!
> It does crash my system/keyboard when i try to quit the test pattern, but > that's probably cuase i'm using a old library. That's strange. Please enable Magic SysRq for debugging purposes and then help us to track that one down. > Now, on a more phychotic note... I read a note about somone sticking a ps/2 > keyboard into thier ps/2 mouse port, and getting it to work. Yes. This is basically possible. Steffen has done that for the "real" KGI before. Don't know, if he ported that back to KGI 0.9 yet. > A employee has just told me that his computer shop has instructed him to > ram his ps/2 keyboard into the serial port on his windows 98 machine. Umm - how would that work ? Maybe with a ps2/serial adapter, like the ones used for mice ... The PS/2 port is basically a clocked serial port, so it might be possible, but I'd rather use the two PS/2 ports for keyboards and the serial ones for mice. CU, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Unidentified subject!
It's been 3 days since the apocalypse and all goes well. I've sucessfully run dual monitor support by buying 2 matrox mileninum 200SD cards, and ramming them in the same system, then booting a 2.3.3x kernel with all the matrox stuff enabled. i then ran a "tile" demo spanning the monitor test pattern accross 2 screens. way cool. It does crash my system/keyboard when i try to quit the test pattern, but that's probably cuase i'm using a old library. Now, on a more phychotic note... I read a note about somone sticking a ps/2 keyboard into thier ps/2 mouse port, and getting it to work. A employee has just told me that his computer shop has instructed him to ram his ps/2 keyboard into the serial port on his windows 98 machine. From a hardware perspective will this work? if so, could we use this as the cheapskates way of testing the multi-keyboard code? (USB keyboards cost around $60 each... ps/2 keyboards are usually laying around with systems being tossed for free) >From: John Fortin <[EMAIL PROTECTED]> > >Please Enough I get enough off topic stuff as it is... > >John happy new years john! *grin* Corey __ Get Your Private, Free Email at http://www.hotmail.com
Re: heretic & new light on old problem. (was Re: Unidentified subject!)
"Firstname Lastname" <[EMAIL PROTECTED]> writes: > yes, i saw that changelog entry. How about mentioning that it requires a > "-mode xres yres" to do it in the docs? ;) A good idea, but I'm not the maintainer of Linux Heretic, so I can't fix it. > as for my problems, i found that for some reason heretic seemed to be > grabbing the 320x240 differntly then when speced with the 320x240. It seems > to flicker in "menu mode" when not refreshing at 214Hz. Strange... Probably related to the way Heretic updates the screen. There's another undocumented option called '-doublebuffer' in ggiheretic, which may help a bit. It's not perfect though. > As for my problems, it seems that i had a screwed up motherboard. It would > die when certain monochrome cards were mixed with vga cards, and would just > not work with other monochrome cards. > > I have switched to a new computer in which the motherboard is screwed up in > a differnt way, and while the video works, the kernel & ggi no longer > compile :/ Umm, maybe you should just go buy a working motherboard. ;-) //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: heretic & new light on old problem. (was Re: Unidentified subject!)
> I have switched to a new computer in which the motherboard is screwed up in > a differnt way, and while the video works, the kernel & ggi no longer > compile :/ What happens ? Sig11 ? Usually indicates a RAM problem. CU, Andy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: Unidentified subject!
> Hmm, it should work, but it have some limitations - here's my Changelog > entry: > * Initial support for higher resolutions (automap, menus, statusbar and > info screens work flawlessly now, but the 3d engine gets messed up or > crashes if vertical resolution exceeds 240. Horizontal resolutions are > limited to the common ones - 320, 512, 640, 800 and 1024 all work fine > but most inbetween causes crashes.) 640x480 does not work right in my copy. Menus appear side-by-side in two small windows at the top of the screen (looks like it is just linearly addressed and it still thinks it has 320x200). However the Game engine is centered to the middle of the screen and runs o.k. there, except for the "head-up-displays" that are misplaced. > Note that there's also a -scale option for ggiheretic, which will > scale the display 2 times. This one works fine for me. I already started wondering how I tested it earlier ... CU, ANdy -- = Andreas Beck| Email : <[EMAIL PROTECTED]> =
heretic & new light on old problem. (was Re: Unidentified subject!)
>Andreas Beck <[EMAIL PROTECTED]> writes: > > > BTW: Heretic has a -mode parameter that should change resolution, >however it > > doesn't seem to work right in my outdated copy. > >Hmm, it should work, but it have some limitations - here's my Changelog >entry: >* Initial support for higher resolutions (automap, menus, statusbar and > info screens work flawlessly now, but the 3d engine gets messed up or > crashes if vertical resolution exceeds 240. Horizontal resolutions are > limited to the common ones - 320, 512, 640, 800 and 1024 all work fine > but most inbetween causes crashes.) > >Note that there's also a -scale option for ggiheretic, which will >scale the display 2 times. > >//Marcus yes, i saw that changelog entry. How about mentioning that it requires a "-mode xres yres" to do it in the docs? ;) as for my problems, i found that for some reason heretic seemed to be grabbing the 320x240 differntly then when speced with the 320x240. It seems to flicker in "menu mode" when not refreshing at 214Hz. Strange... As for my problems, it seems that i had a screwed up motherboard. It would die when certain monochrome cards were mixed with vga cards, and would just not work with other monochrome cards. I have switched to a new computer in which the motherboard is screwed up in a differnt way, and while the video works, the kernel & ggi no longer compile :/ Corey __ Get Your Private, Free Email at http://www.hotmail.com
Re: Unidentified subject!
Andreas Beck <[EMAIL PROTECTED]> writes: > BTW: Heretic has a -mode parameter that should change resolution, however it > doesn't seem to work right in my outdated copy. Hmm, it should work, but it have some limitations - here's my Changelog entry: * Initial support for higher resolutions (automap, menus, statusbar and info screens work flawlessly now, but the 3d engine gets messed up or crashes if vertical resolution exceeds 240. Horizontal resolutions are limited to the common ones - 320, 512, 640, 800 and 1024 all work fine but most inbetween causes crashes.) Note that there's also a -scale option for ggiheretic, which will scale the display 2 times. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED]
Re: Unidentified subject!
Hi !
> >If the appropriate modes are not found, the LibGGI driver will not be able
> >to give timings to the card, which usually results in bad timings. You
> >should have gotten a warning about that at runtime.
> Yes, i translated my X modes useing modeline2fb into a /etc/fb.modes file to
> no avail.
Do you really have an X mode set up and working for 320x240 ?
Please test that mode with the X server. If that isn't it, it might be
something with not parsing additional hints correctly or similar.
BTW: Heretic has a -mode parameter that should change resolution, however it
doesn't seem to work right in my outdated copy.
> however when i first started i had no /etc/fb.modes file...
> where should i find the error message if something is wrong with
> /etc/fb.modes?
Wait ... oh - it's a debug-message:
/* Try to get the timing from the standard database */
if (get_timing(TIMINGFILE,&var)) {
GGIDPRINT_MODE("display-fbdev: cannot get timing from"
TIMINGFILGFILE". Just hoping it works.\n");
}
You can enable full debugging comments on LibGGI using GGI_DEBUG=255.
Running a program like GGI_DEBUG=255 ./program 2>logfile will provide us
with lots of useful debugging info, if something goes wrong.
> exactly :) anyone we should tell? the [EMAIL PROTECTED] list?
> (someone told me about that one today)
Yes, probably. Or maybe better the author of the fb driver in question.
It was the ATI Mach, IIRC - right ?
Looks like the current maintainer is:
* Copyright (C) 1998 Eddie C. Dost ([EMAIL PROTECTED])
However we can try to collect some extra debugging data first. Run the
GGI_DEBUG probe, and maybe we can narrow down the problem.
> >No. kgicon is an alternate driver model that is capable of producing
> >drivers
> >for various environments, including fbcon.
> >If you fbcon is working fine, there is no need to use kgicon.
>
> How does that differ from KGI?
Well - the basic idea we had, was to unify graphics driver development.
The KGI system is a general setup we use for driver development. The
resulting drivers can be linked to glue layers that vary between the
environment the driver will run in.
Up to now there are four such environments:
1. fbcon/kgicon. The driver will be linked with a glue-layer, that will make
it look like a standard fbcon driver. This is the preferred usage for now.
2. "real" KGI 0.0.9. This is a new design maintained by Steffen Seeger,
which requires heavy patching of the Linux console system to work. This is
in the flux, but stabilizing now. Moreover the drivers need to be changed
a bit to work with and take advantage of the advanced environment KGI
provides.
3. suidkgi. I haven't checked that for a long time, as it is IMHO a bad
hack, though it was useful to prove the concept of the abstract graphics
drivers. It will link the whole driver into a LibGGI target module which
is directly loaded and executed by the application. This requires root
priviledges for the application, of course.
4. Some other mysterious OS. I can't tell anything about it, but I can
assure you, that the KGI drivers for at least VGA, Permedia 2 and MediaGX
work fine, there.
> >You mean a /etc/fb.modes ?
> yes, i created it using the modeline2fb program. It seemed to have no
> effect.
And you created a mode for the resolution that failed to set ?
And the mode works fine when trying it with fbset ?
> cool! I've got access to some Diamond Stealth 2000/3000's, a Voodo banchee,
> a ATI Mach 64, a Trident TGUI9440-1, and some STB powergraph 64 (trio64V+)
> cards (all PCI). Would any of them do it and have a driver available?
I have to leave the answer to someone else here.
CU, ANdy
--
= Andreas Beck| Email : <[EMAIL PROTECTED]> =
Re: KGI vs KGIcon vs fbcon confusion (was Re: Unidentified subject!)
On Wed, 15 Dec 1999, Firstname Lastname wrote: > ok, I'm fuzzy here. if libggi can use KGI or fbcon, then why make a KGIcon > driver (differnt fron the KGI driver) which redirects KGI calls to fbcon > calls? kgicon is a way to use KGI drivers without patching the kernel, by having them emulate and extend the kernel's built-in fbcon interface. > what is KGI supposed to do that fbcon does not? > (and KGIcon is not just a differnt name for KGI, right?) Nope. KGIcon is a limited form of KGI. KGI isn't limited by the design of the Linux kernel because it patches the kernel, so it can do a lot more things e.g. using the page fault handler and keeping the hardware completely secure from even malicious applications. KGIcon supports the interfaces of KGI that don't need to patch the kernel, like the KGI mode setting API -- things that we feel are better implemented in KGI than in the fbdev design, or it can also be used where there's a KGI driver but not an fbdev driver for a certain chipset in order to get the fbcon API working on that chipset. A whole discussion of the differences in design between fbdev and KGI would make this a long and redundant post -- there's stuff on the WWW site about KGI's design and the reasons behind it. -- Brian
Re: KGI vs KGIcon vs fbcon confusion (was Re: Unidentified subject!)
On Wed, 15 Dec 1999, Firstname Lastname wrote: > > >Well. Concerning this issue, currently, with GGI: you do not need to patch > >your kernel, but you can of course if you really insist in doing it. > >It may sound funny, but, in fact: > > - KGIcon is a bridge that allows to use KGI (1998 version) drivers > >within the context of the (now standard) linux fbcon/fbdev API. It also > >allows to use standard fbdev-only hw drivers (unless I stand corrected). > > ok, I'm fuzzy here. if libggi can use KGI or fbcon, then why make a KGIcon > driver (differnt fron the KGI driver) which redirects KGI calls to fbcon > calls? In order to be able to use the KGI drivers without having to patch the kernel. You lose quite some KGI functionality by doing this (no new console system, no input device handling, no memory mapping optimizations, etc), but you can still use the KGI drivers. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: Unidentified subject!
> > Anyway, my system booted and i got the penguin on bootup, and figured >all > > must be working just peachy... then i went to run heretic as a demo... >My > > screen started jumping, and my monitors menu had a cow. It reported >that > > the video card was trying to refresh at 214Hz. > >If you use a standard fbcon dirver, you have to set up modelines for it. > >Look at the fbset utility that comes with the degas source tree or is >available from other sources. > >These modes are described in /etc/fb.modes > >If the appropriate modes are not found, the LibGGI driver will not be able >to give timings to the card, which usually results in bad timings. You >should >have gotten a warning about that at runtime. Yes, i translated my X modes useing modeline2fb into a /etc/fb.modes file to no avail. however when i first started i had no /etc/fb.modes file... where should i find the error message if something is wrong with /etc/fb.modes? > > I later found (using the monitor test demo) that whenever i go to > > 320x240 it pushes it to 214Hz (acording to my monitor). 640x480 seems > > to work fine. 800x600 8bpp says not enough memory. >This is a bit strange. 800x600x8 only needs half a meg of RAM, so ... >We might be able to find a bug here ... exactly :) anyone we should tell? the [EMAIL PROTECTED] list? (someone told me about that one today) > > I have lately heard reference to KGIcon, which seems to be some kind of > > module to load in. Do i need this if i'm getting the penguin and other > > 640x480 8bpp tests are working? > >No. kgicon is an alternate driver model that is capable of producing >drivers >for various environments, including fbcon. >If you fbcon is working fine, there is no need to use kgicon. How does that differ from KGI? > > (by the way i've created a modes database from the XF86Config database, > > which used to work ok, and it's still going nutty) > >You mean a /etc/fb.modes ? yes, i created it using the modeline2fb program. It seemed to have no effect. > > I've noticed multi-heading options only under matrox drivers, is matrox >the > > only brand which will nicely remap thier addresses to allow more then >one > > card in the system? > >No - most modern cards should allow this. I'll give a Dualmon setup with my >Permedia a try again some day soon. Should work. cool! I've got access to some Diamond Stealth 2000/3000's, a Voodo banchee, a ATI Mach 64, a Trident TGUI9440-1, and some STB powergraph 64 (trio64V+) cards (all PCI). Would any of them do it and have a driver available? if not, where can i get a list of the cards that do? >CU, ANdy >Andreas Beck | Email : <[EMAIL PROTECTED]> Thanks for your help, Corey __ Get Your Private, Free Email at http://www.hotmail.com
KGI vs KGIcon vs fbcon confusion (was Re: Unidentified subject!)
>Well. Concerning this issue, currently, with GGI: you do not need to patch >your kernel, but you can of course if you really insist in doing it. >It may sound funny, but, in fact: > - KGIcon is a bridge that allows to use KGI (1998 version) drivers >within the context of the (now standard) linux fbcon/fbdev API. It also >allows to use standard fbdev-only hw drivers (unless I stand corrected). ok, I'm fuzzy here. if libggi can use KGI or fbcon, then why make a KGIcon driver (differnt fron the KGI driver) which redirects KGI calls to fbcon calls? what is KGI supposed to do that fbcon does not? (and KGIcon is not just a differnt name for KGI, right?) > - libggi, the library runs on top of KGIcon, or on fbdev, or on X11... >Theoretically it should run over anything, at anytime, anywhere, etc. >(If it does not, report bugs to Andreas. ;-) > - KGI 0.9 the 2000 version is currently being polished by Steffen Seeger >and Jon Taylor. To try this one, you need to patch your kernel, to write >your own device drivers for your favourite card, and more generally, >be a _real_ man. But that's the funniest part (unless you want to do >some production things with KGI). > >Well. I will stand corrected. Sure. > >Rodolphe Thanks, Corey __ Get Your Private, Free Email at http://www.hotmail.com
Re: Unidentified subject!
Hi ! > I am running debian, so i installed the libggi2 package, and the libgii > package, etc. Then i went to put kgi in my kernel. I found > framebufferconsole (fbcon) support, and thought that kgi stuff was renamed > to fbcon, so i selected it for my ATI mach64 PCI video card. (selected vesa > & ATI driver). You activated the standard kernel ATI driver, then. This should work. I do not know the state of the kgicon ATI driver, but I suppose that you are for now better off with using the kernel version. > Anyway, my system booted and i got the penguin on bootup, and figured all > must be working just peachy... then i went to run heretic as a demo... My > screen started jumping, and my monitors menu had a cow. It reported that > the video card was trying to refresh at 214Hz. If you use a standard fbcon dirver, you have to set up modelines for it. Look at the fbset utility that comes with the degas source tree or is available from other sources. These modes are described in /etc/fb.modes If the appropriate modes are not found, the LibGGI driver will not be able to give timings to the card, which usually results in bad timings. You should have gotten a warning about that at runtime. > I later found (using the monitor test demo) that whenever i go to > 320x240 it pushes it to 214Hz (acording to my monitor). 640x480 seems > to work fine. 800x600 8bpp says not enough memory. This is a bit strange. 800x600x8 only needs half a meg of RAM, so ... We might be able to find a bug here ... > I have lately heard reference to KGIcon, which seems to be some kind of > module to load in. Do i need this if i'm getting the penguin and other > 640x480 8bpp tests are working? No. kgicon is an alternate driver model that is capable of producing drivers for various environments, including fbcon. If you fbcon is working fine, there is no need to use kgicon. Does anyone here know more about the status of the kgicon ATI driver ? Would it be worth a try ? > also, how do i get the "setmon" utility? i've heard about it, but don't see > it anywhere. You can not use it with the stock kernel fbcon drivers. With a kgicon driver it would allow you to download the monitor characteristics to the driver, which allows us to bypass the nasty modeline problem, as the kgicon driver can calculate timings on the fly. > The matrox fbcon driver references being able to set the refresh rate, does > the ATI Mach 64 just lack that support? No. Any fbcon driver usually _must_ set its refresh rate, as the complete timings are given at mode setup time. > (by the way i've created a modes database from the XF86Config database, > which used to work ok, and it's still going nutty) You mean a /etc/fb.modes ? > I've noticed multi-heading options only under matrox drivers, is matrox the > only brand which will nicely remap thier addresses to allow more then one > card in the system? No - most modern cards should allow this. I'll give a Dualmon setup with my Permedia a try again some day soon. Should work. CU, ANdy -- Andreas Beck | Email : <[EMAIL PROTECTED]>
Re: Unidentified subject!
Firstname Lastname wrote: > Hello. After haveing put some effort into trying to get GGI working on my > system, I am now quite confused. Some of your 'renaming' assumptions are wrong. So, for example, fbcon and KGIcon are _separate_ things. > > I am running debian, so i installed the libggi2 package, and the libgii > package, etc. I think these packages are outdated now. You should grab a copy of the source tree from CVS (see http://www.ggi-project.org) and recompile. > I should be specifically clear that I have not patched my kernel at all, and > am confused why 640x480 is working for me, if i'm supposed to patch it. Well. Concerning this issue, currently, with GGI: you do not need to patch your kernel, but you can of course if you really insist in doing it. It may sound funny, but, in fact: - KGIcon is a bridge that allows to use KGI (1998 version) drivers within the context of the (now standard) linux fbcon/fbdev API. It also allows to use standard fbdev-only hw drivers (unless I stand corrected). - libggi, the library runs on top of KGIcon, or on fbdev, or on X11... Theoretically it should run over anything, at anytime, anywhere, etc. (If it does not, report bugs to Andreas. ;-) - KGI 0.9 the 2000 version is currently being polished by Steffen Seeger and Jon Taylor. To try this one, you need to patch your kernel, to write your own device drivers for your favourite card, and more generally, be a _real_ man. But that's the funniest part (unless you want to do some production things with KGI). Well. I will stand corrected. Sure. Rodolphe
Unidentified subject!
Hello. After haveing put some effort into trying to get GGI working on my system, I am now quite confused. I am running debian, so i installed the libggi2 package, and the libgii package, etc. Then i went to put kgi in my kernel. I found framebufferconsole (fbcon) support, and thought that kgi stuff was renamed to fbcon, so i selected it for my ATI mach64 PCI video card. (selected vesa & ATI driver). Anyway, my system booted and i got the penguin on bootup, and figured all must be working just peachy... then i went to run heretic as a demo... My screen started jumping, and my monitors menu had a cow. It reported that the video card was trying to refresh at 214Hz. I later found (using the monitor test demo) that whenever i go to 320x240 it pushes it to 214Hz (acording to my monitor). 640x480 seems to work fine. 800x600 8bpp says not enough memory. I have lately heard reference to KGIcon, which seems to be some kind of module to load in. Do i need this if i'm getting the penguin and other 640x480 8bpp tests are working? also, how do i get the "setmon" utility? i've heard about it, but don't see it anywhere. The matrox fbcon driver references being able to set the refresh rate, does the ATI Mach 64 just lack that support? (by the way i've created a modes database from the XF86Config database, which used to work ok, and it's still going nutty) I've noticed multi-heading options only under matrox drivers, is matrox the only brand which will nicely remap thier addresses to allow more then one card in the system? I should be specifically clear that I have not patched my kernel at all, and am confused why 640x480 is working for me, if i'm supposed to patch it. Thanks for any help, Corey __ Get Your Private, Free Email at http://www.hotmail.com
Unidentified subject!
unsubscibe [EMAIL PROTECTED]
