Hello all!  To usher in the new millenium, I present to you a nice
fat chunk of updates that I have made to KGI-0.9 over the last two weeks,
which I had on vacation.  Steffen is a very very busy man recently with
all his Ph.D work, so I thought I'd do some housecleaning and fixing-up of
things here and there for him.  I'm not quite done yet, tomorrow is the
last day of my vacation and I still have a few loose ends to tie up (see
below).  But I wanted to tell you all about the new stuff tonight, so here


1. Three new drivers:

        A. nVidia TNT2

                a. Detects and maps card and reigons
                b. Sets/mmap()s VGA textmodes 
                c. All registers #defined and struct{}'ed
                d. VGA and MMIO DAC registers read from card
                e. No accels yet
                f. No MMIO-only mode yet
        B. S3 ViRGE

                a. Detects and maps card and regions
                b. Sets/mmap()s VGA textmodes
                c. All registers #defined and struct{}'ed
                d. VGA registers read from card
                e. Accels driver skeleton but no code yet
                f. No MMIO-only mode yet

        C. IBM VGA (graphics)

                a. Skeleton; no working logic yet

        None of the drivers does anything but textmodes yet, but now that
I'm finally done with building the driver frameworks, graphics modes
available on both cards should roughly correspond to those available from
the KGIcon drivers, since that's where most of the code will probably come
from |->. If I get the time tomorrow, I'll fill in what I can of the TNT2
modesetting code, but for ViRGE I leave that task to Jos and the other
ViRGE hackers.  I think you guys will find the port to be quite easy.  If
someone else has some free cycles, fleshing out the VGA driver will be
even easier, since there are no accels and part of it is already written
in the existing VGA-text driver.


2. LibKGI.  This is a typical crossplatform libtool library package, with
a bunch of functions and datatypes to enable crossplatform portability and
consistency for the KGI-0.9 functions and abstractions.  These were lifted
out of Steffen's KGI demo code, which still needs to be rewritten to use
the library.  Again, tomorrow |->. The yet-to-be-written LibGGI target for
KGI-0.9 will use LibKGI primitives instead of read/write/mmap/ioctl, which
will be a portability godsend when I start working on a Win32 version of


3. New accel subsystem with sample skeleton ViRGE accels driver.  No big
deal, just fleshing out the whole build system.  It would have been nice
if I had had a little more time to do some work on the ViRGE accels
myself, but my Dad's computer has the ViRGE card and it has to stay here
in Sacramento while I have to go home to San Jose.  

        A hint for anyone working on ViRGE accels: If you didn't already
know, the sample driver that comes with the old DirectX 5 DDK is for a
ViRGE!  It kind of sucks to have to download 7+ megs of DDK just to get
the ViRGE driver code, but that code is a gold mine.  Good stuff.  I
wouldn't have been able to write the ViRGE registers handling code and
#defines without the Win32 code to refer to, since my databook for ViRGE
has apparently wandered off somewhere....


4. Lots of little cleanups all over the place in the core kernel code:
Makefiles, debugging, stuff like that.


5. The Magic SysRq key now works!  Man, it _sucked_ not having that
available when debugging, and it sure is nice to have it back.  And
speaking of debugging...


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 |->.


7. A kernel 2.3.31 version of the KGI patches.  I created this a while
ago, but it has the same psaux bug as KDB, as well as a few other oopsen.
I'll bug Steffen to put it in his master tree anyway, so people can hack
at it.  But I am still doing all my KGI-0.9 development under 2.2.13 for


8. KGI-0.9 LibGGI target.  No I haven't even started this one yet, but it
won't be difficult at all.  I should be able to get a basic unaccelerated
target working by the end of tomorrow.  This one is #1 on the priority
list for tomorrow.


        So there you have it.  Hopefully I will be able to wrap up the
LibGGI target and get some graphics modesetting code into the TNT2 driver
tomorrow, so I can wrap this whole episode up cleanly.  I probably won't
be able to do much KGI/GGI coding for a little while since I have several
new projects starting at work in addition to the Emu10k1 driver which is
already eating all my time.  And if I do work, it will probably need to be
GGIMesa target coding, since the KGI-0.9 accels support is now just about
far enough along that my support is not needed there so much anymore.

        KGI-0.9 is really coming together.  I am quite pleased with the
job Steffen has done, how powerful the system is, and at how easy it is to
work with.  And the accels support is just fantastic!  I can't wait to see
what this puppy can do when we get the Permedia2 or ViRGE drivers running
accels, and now that Matrox and ATI have released specs and there is quite
a bit of extant GLX code for their chipsets to use as a reference, we
finally have the opportunity to showcase the true power of in-kernel
acceleration support and ping-pong buffering.

        I am flying out to the LinuxWorld Expo at New York City at the
beginning of February with my boss.  We will be speaking at Eric Raymond's
'open source device drivers' conference session, which should be
interesting |->.  What would be even more interesting, however, would be
if I had a working prototype of KGI-0.9 + driver accels + LibGGI target
support + GGIMesa 3D accels target support.  In other words, the complete
top-to-bottom GGI/KGI solution that we have all been working towards for
years now.


        We are getting very close to this goal now, and I would like to
once again encourage everyone who is reading this and has any free time to
pitch in and help tighten down KGI-0.9.  Even if all you have time to do
is download the latest patches and test them over your lunch break while
reading Slashdot, that would still be helpful.  Or you could take 30
minutes and knock together a skeleton driver for your favorite chipset,
and maybe that will make it easier for the next guy to add some I/O
routines, and then the next guy can type in some register #defines, etc
etc etc and before you know it you'll have a real driver on your hands.
Every little bit helps, folks.  If you really believe in GGI/KGI, as I do,
then please try to do whatever you can at this critical juncture to help
it become the success it has the potential to become.


        Wow, I gotta go to bed.  Anyway, that's all for now.  I'll get
back to you all tomorrow evening with some patches/tarballs to tide you
over until Steffen can get this stuff integrated into his master


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

Reply via email to