On Wed, 5 Jan 2000, Brian S. Julin wrote:

> On Sun, 2 Jan 2000, Jon M. Taylor wrote:
> > 1. Three new drivers:
> > 
> >     A. nVidia TNT2
> Cooincidentally I just switched to a Diamond TNT2 based card, so I
> will try to give it a spin.  

        There's not much there yet, but there is enough working I/O code
that it should be easy to add code the handle all MMIO ("control")
registers, not just the six or so DAC MMIO registers that are currently
handled by the driver.  The Riva series card have very logical and
well-organized MMIO register layouts.  And then it should be easy to port
the existing hardware programming code from the KGIcon driver.

        I had hoped to have the time to do a lot of refactoring of the
existing KGIcon driver sources in the course of the port to KGI-0.9; the
current code is the quite obfuscated code which came from the XFree86
sources.  It is not very easy to understand, nor is it very "KGI like".  
A lot of the mode setup code is just a predefined series of register
values which are blindly dumped to the hardware.  Ack!  |-<.

        But if you don't have a lot of time, it would be far better to
just port the existing code over and wait until later to refactor it.  At
least we'd have a working driver of some kind, and we'll not be seeing any
decend accels performance anyway until nVidia releases their DMA docs.

> What's the deal on TNT2 docs --
> anyone got a link collection for sample code?

        AFAIK, all that exists is the KGI code (which is largely older
XFree86 code), the newest XFree86 code, and the GLX code.  I think the GLX
people have non-DMA triangles working at least, so that might help.
> >     C. IBM VGA (graphics)
> > 
> >             a. Skeleton; no working logic yet
> Hmm, quandry -- I'll have to decide whether to make the SVGA the 
> boot display and work on the TNT (thus having to edit the bios settings
> whenever I need to play i82 :), or keep the TNT as the primary display
> and work on VGA... or has the boot display vs KGI issue been solved?

        If you mean the BIOS POST problem, no.  KGI-0.9's boot init code
really does need to open a vm86() real-mode box and POST all the video
BIOSes which are present in the system.  And even that will only work on
x86 machines |-/.  XFree86 4.0 will come with x86 real mode emulator code
to get around this problem |-/.

> I suppose we need a vga driver pretty badly.

        Yes, so more people can play with KGI-0.9.
> > 6. KDB now works with KGI, except for one last bug in the psaux keyboard
> > driver code which causes the KDB command parser to hang in an infinite
> > loop with interrupts disabled |-<.  I suspect a conflict between Steffen's
> > psaux code and KDB, which expects to run with the standard kernel psaux
> > code.  Having KDB available alongsize KGI will make driver development
> > much, much more pleasant and convenient.  Not tommorrow, however |->.
> Have you tried it with the input-linux patch yet?  

        Nope.  I only messed around with KDB for a few hours until I
realized that the psaux code was at fault, and then I decided that I
needed to spend the rest of my vacation time working on something more
immediately valuable.


'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
        - Scientist G. Richard Seed

Reply via email to