Re: Massive KGI-0.9 update
On Sun, 2 Jan 2000, Jon M. Taylor wrote:
>
> 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
>
I'm working on it now, so please contact me if you want to help for the
ViRGE. It would be very nice if we could use CVS for the KGI
tree. Steffen, Jon, can we please go back into CVS please ?
Current state of my code: Clock driver done. Chipsetdriver contains almost
all code, only checking must be done (still figuring out how to determine
the mode, this is quite different form the kgicon drivers...) Ramdac
driver inserted in chipset driver due to lack of register access in the
ramdac driver. Ramdac driver is an empty (but compiling) sceleton.
Is the problem that the KGI-card must be the second card solved already
? A ViRGE can't be a second card (At least not my DX).
Jos
Chipset Docs (was Re: Massive KGI-0.9 update)
On Wed, 5 Jan 2000, Jon M. Taylor wrote: > myself any troubles with M$. Better safe than sorry. Perhaps this should > be listed in a FAQ somewhere, since a lot of people have been asking me > about these ViRGE sources...? If people want to send me lists of links for documentation, I can compile it all for the WWW pages developers section. If you send something and you're not sure about the terms under which it can be distributed, please say so and I'll try to find out. BTW, If Steve or Marcus could apply that patch I sent for the WWW site that would be dandy; I'm starting to get emails about the broken links. -- Brian
Re: Massive KGI-0.9 update
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.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Re: Massive KGI-0.9 update
On Wed, 5 Jan 2000, Rodolphe Ortalo wrote: > BTW Jon, could you send me this 'Win32' driver source that you have ? > I happen to have ViRGE somewhere and a spare computer now... http://download.microsoft.com/download/win98/DDK/5/W9X/EN-US/dx5ddk.exe I just read the license text, and it specifically states that I am not allowed to redistribute the DDK or any part thereof. So unfortunately that means that people who want to examine the sample ViRGE sources will have to download the whole 7+ megs package themselves from M$, at the URL given above |-<. Sorry about that, but I don't want to cause GGI or myself any troubles with M$. Better safe than sorry. Perhaps this should be listed in a FAQ somewhere, since a lot of people have been asking me about these ViRGE sources...? Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: Massive KGI-0.9 update
Hi Jon's code contains a little bug, the splash screen doesn't compile. It will work after applying this patch on top of Jon's. (attachment 1) Besides, don't enable the kernel debugger in the 2.2.13 kernel, for compiling will fail. As far as I can see, this has to do with the fact that the debugger needs some structures that are removed by applying this patch. A pity, but for now, take it or don't install till we got a real update. (Jon, you already recieved this in your personal mailbox) Jos *** linux/drivers/kgi/dpy-i386.cWed Jan 5 19:39:30 2000 --- linuxkgi/drivers/kgi/dpy-i386.c Wed Jan 5 19:19:27 2000 *** *** 834,840 # ifdef CONFIG_KGI_SPLASH ! kgi_boot_fb[boot_pos] = *s | (boot_fb[boot_pos] & 0xFF00); /* slow down to be able to read early boot messages ** even when they scroll up. --- 834,840 # ifdef CONFIG_KGI_SPLASH ! kgi_boot_fb[kgi_boot_pos] = *s | (kgi_boot_fb[kgi_boot_pos] & 0xFF00); /* slow down to be able to read early boot messages ** even when they scroll up.
Re: Massive KGI-0.9 update
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. What's the deal on TNT2 docs -- anyone got a link collection for sample code? > 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? I suppose we need a vga driver pretty badly. > 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? I've meddled with Steffen's psaux code before so I will try and take a look. Never used KDB before but it sounds worth learning. (Sigh, there are still some mainboard timing kinks in my current system so things crash occasionally for no reason -- I hope that doesn't have me chasing nonexistant bugs.) > 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. I second this sentiment. Even if you're just doing it to learn how to write kernel code, please play with KGI. -- Brian
Re: Massive KGI-0.9 update
Thank you for all this work. Steffen, I guess you will tell us when you have a KGI distrib. with these things? Rodolphe "Jon M. Taylor" wrote: > 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. > Acknowledged. So, 2000 may be interesting indeed... BTW Jon, could you send me this 'Win32' driver source that you have ? I happen to have ViRGE somewhere and a spare computer now... R.O.
Massive KGI-0.9 update
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
goes:
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
KGI.
==
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
now.
==
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
