Hi,
> > Yeah. I agree. So you want to do some HW driver programming ?
> Yes, and having GGI run on my console isn't a bad side effect. :)
*grin*
> > If you have the docs, you are almost there. Good HW docs usually even
> > contain example programming sequences.
> I fear that there are no docs for these chips...
Then you can UTSL and try the XFree drivers.
> > Hmm - getting the River driver to work maybe ? :-)
> River? Do you mean Riva? Or is this a project I'm not familiar with?
Auto-spell-checker in my brain got me again ... of course I mean Riva.
> A LibGGI target for a printer would be interesting...
> Unfortunately, I don't have any extra devices like those.
*grins* ghostscript could emulate a printer for you :-). But well - no, it
isn't really fun making something as artificial as that work. Moreover
kind of a printer target can be done using the file target and something
like pnmtops.
> > I don't have information on that one. However I found, that it _is_ pretty
> > easy to analyze Windows drivers if you knwo enough about x86 assembly
> > and have some decent disassembling tools.
> Yikes. I imagine I *could* do that, but I'd prefer not reach that point.
> It's frustrating enough being forced to reboot when you mess up your
> video card; being forced to boot between Windows/Linux regularly would
> be painful.
Yeah. However sometimes it is plain necessary. When I did the VideoIO stuff
for my current card, I had the docs about the I2O helper chips that actually
did the job, and had found enough about the interfacing, so I thought it
should work, but all I got was garbage. Only disassembling the Win driver in
depth showed me, that due to a broken board design the bus had to be
unlocked in some versions of the card ...
> Thank you for your offers of help. I'll glance at the XF source and
> see if I understand any of it.
O.K. - have fun. A short report about the new XF driver structure and how
understandable it is would be welcome in any case.
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
