kgi-0.9-20000222
Hello, a new KGI-0.9 snapshot is available from http://www.tu-chemnitz.de/~sse/ggi/kgi-0.9-2222.tar.gz 1) CHANGES === 2222: - merged jmt3 branch by Jon M. Taylor: - added generic VGA driver framework by Jon M. Taylor - added nVidia TNT2 driver framework by Jon M. Taylor - added S3 ViRGE driver framework by Jos Hulzink - added fixed clock driver - merged Matrox Gx00 driver by Johan Karlberg (Gx00-degas-4): - added Gx00 driver framework - added XGGI framework, simplified build and patching process - this does not compile yet - simplified patch build process for kernels and X servers Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse --- The GGI Project: http://www.ggi-project.org ---
Re: evstack, Results of multi-headed quake test, and input fun
I've had many email pass between Joseph Kain and myself... I usually send anyone with a Glide problem I can't answer his way (poor guy!) I can imagine. He seems like a really nice guy. I answer question about fbdev all the time. There is a GGI Glide target, but it's 2D. What's wanted is accellerated hardware 3D.. Something that CAN render 3 screens of Quake at a decent FPS. = I agree. So where do we start? First voodoo cards like many cards are triangle bases. Any triangle support? The next thing is how to program the libggi target to use things like textures, alpha blending and depth buffering. Codito, ergo sum - "I code, therefore I am" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
Re: evstack, Results of multi-headed quake test, and input fun
There is a GGI Glide target, but it's 2D. What's wanted is accellerated hardware 3D.. Something that CAN render 3 screens of Quake at a decent FPS. = I agree. So where do we start? First voodoo cards like many cards are triangle bases. Any triangle support? The next thing is how to program the libggi target to use things like textures, alpha blending and depth buffering. What is the future of Glide in the 3dfx plan of things? Given that there are (some) Glide programs that could run directly on a GGI Glide 3D target, and there is a Mesa-glide target, this would perhaps be the easiest way to go. It keeps the 3Dfx development rather apart from other Linux 3D development, and while it provides a demonstration of principle for GGI 3D it doesnt help support other cards, and now with full scpecs glide is not necessary. Justin
screen hosings...
Sometimes when i'm running X and run fbset (using the fbdev matrox driver), my screen hoses... if i switch VC's my screen is still hosed. however, if i type, sometimes i will see letters flash on the screen for about a tenth of a second, then disapear. if i run quake all the colors are wrong. Is there a command to re-initialize/reset the fbdev driver? Corey __ Get Your Private, Free Email at http://www.hotmail.com
Re: kgi-0.9-20000222
On 2000/Feb/22, Steffen Seeger wrote: Hi, a new KGI-0.9 snapshot is available from What about acceleration? I've downloaded this version but it has nothing under the accel directory... Is it only available at KGIcon yet? - added S3 ViRGE driver framework by Jos Hulzink Cool! -- __ )_) \/ / / email: mailto:[EMAIL PROTECTED] / \ / (_/ www : http://programacion.mundivia.es/ryu [ GGL developer ] [ IRCore developer ] [ GPUL member ]
Re: evstack, Results of multi-headed quake test, and input fun
On Mon, 21 Feb 2000, Joseph Carter wrote: On Mon, Feb 21, 2000 at 02:42:20PM -0500, James A Simmons wrote: Their does exist a fbdev drivers for this card. The problem is I don't have such a card nor the money at this time to buy it (hint). I would enjoy creating something like Msrcus did for the matrox cards. Of course I like to milk it for more than drawing boxes. There is a GGI Glide target, but it's 2D. What's wanted is accellerated hardware 3D.. Something that CAN render 3 screens of Quake at a decent FPS. = GGIMesa needs its own Glide target, to work with the basic LibGGI Glide target. When GGIMesa is attached to a visual context, it will attempt to load a target which matches the already-loaded LibGGI target. The GGIMesa target will then transparently extend the functionality of the the underlying LibGGI target for its own purposes. In the case of GGIMesa+Glide, the extensions involved would make use of the triangle drawing functions etc in Glide which are not used by the underlying LibGGI Glide target. If the base LibGGI target implements any sort of control interface on top of Glide (mutexes, primitive queueing, directbuffer mapping, etc), those features should be used and if necessary extended by the corresponding GGIMesa target. This allows for a nice type of runtime polymorphism in the target code. KGI would definitely make the best target environment to demonstrate the full power of this technique, but I must admit that Glide support would probably be a LOT easier to code up. We already have a nice LibGGI Glide target, and the Glide code in Mesa right now has been developed for some years already and should be easy to steal for our purposes. And a basic GGIMesa 3D accelerated target is not at all difficult to write, I did this last year for Savage4/KGI (ioctl interface) in a few days. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: evstack, Results of multi-headed quake test, and input fun
On Tue, 22 Feb 2000, James A Simmons wrote: There is a GGI Glide target, but it's 2D. What's wanted is accellerated hardware 3D.. Something that CAN render 3 screens of Quake at a decent FPS. = I agree. So where do we start? 1: Make the basic LibGGI Glide target do everything it can do within the LibGGI control scope. Map all regions into DirectBuffers, support the ResourceAcquire() family of functions on all exposed resources, etc. I think that Marcus has already done a lot of this. This stuff will be needed if LibGGI and its extensions are to be able to concurrently access the same Glide instance properly. 2: Write a GGIMesa Glide targfet which does nothing except load itself properly when it is detected that LibGGI is using a Glide target. Examples of GGIMesa targets which do this (fbdev and genkgi) are already available in the current GGIMesa sources. 3: Port the existing FXMesa sources over to the Glide GGIMesa target. Almost all the code should be unchanged, so although there is a lot of FXMesa source code I think that the changes needed to turn it into a GGIMesa Glide target should be quite minimal. First voodoo cards like many cards are triangle bases. Any triangle support? There are triangle primitives supported in LibGGI2D, but LibGGI2D has not been worked on as far as target extension is concerned. GGIMesa is not yet perfect in this regard, but it is a LOT farther along. The next thing is how to program the libggi target to use things like textures, alpha blending and depth buffering. I think that most of those type of features will be mapped into resources or directbuffers by the libggi target code, but the LibGGI API itself does not handle such things: * Texturing == LibGGI2D and GGIMesa * Alpha == LibGGI2D, GGIMesa and possibly LibGWT * Depth buffering == GGIMesa Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
Re: evstack, Results of multi-headed quake test, and input fun
On Tue, 22 Feb 2000, Justin Cormack wrote: There is a GGI Glide target, but it's 2D. What's wanted is accellerated hardware 3D.. Something that CAN render 3 screens of Quake at a decent FPS. = I agree. So where do we start? First voodoo cards like many cards are triangle bases. Any triangle support? The next thing is how to program the libggi target to use things like textures, alpha blending and depth buffering. What is the future of Glide in the 3dfx plan of things? Given that there are (some) Glide programs that could run directly on a GGI Glide 3D target, and there is a Mesa-glide target, this would perhaps be the easiest way to go. I agree. Glide is EOLed, but it is also still very well supported in Linux and GGI. This makes Glide a very good candidate for a first-cut prototype implementation of GGI-based 3D acceleration. It keeps the 3Dfx development rather apart from other Linux 3D development, and while it provides a demonstration of principle for GGI 3D it doesnt help support other cards, and now with full scpecs glide is not necessary. But it is available now, works well, Mesa driver code is already available, and it would also help to exercise the GGI extension and target overloading system to shake out bugs or design issues before we go crazy with GGIMesa fbdev/KGI/DRI/etc targets. Glide-on-Linux seems IMHO like the best target environment to start with. Jon --- 'Cloning and the reprogramming of DNA is the first serious step in becoming one with God.' - Scientist G. Richard Seed
portable
hi all,i want to know how portable ggi is (is all ansi c? how much percent is portable? what is the first module to be port? what enviroment are needed (since i think it need some others lib's)) and what are the good and bad points about it.i really like ggi and ggi/picasso project but i think it is too linux (posix) glued!i am looking very close the aros progress, and by now there is some discussion about a 3D api (what apear mesa to be the win), and i would like to show ggi as an alternative.i don't thin ggi could fit only on the 3D api, but on much more, aros is in development and it preserve the amiga os compatibility, but sure it could be better than amiga os is and the ggi lib would prove that, it is open sourced and i think it would be a very nice desktop os (not a server or development enviroment, as i think posix is the best!)kind regards,jaime dias
Re: screen hosings...
Corey writes: Sometimes when i'm running X and run fbset (using the fbdev matrox driver), my screen hoses... A normal X server, or an fbdev/GGI one ? A normal X server will program the hardware directly, I guess that normally is fine since it puts the console in KD_GRAPHICS mode (telling fbcon to bugger off). But then you run fbset or the fbdev target, and it the kernel tries to program the hardware (using wrong data, since the X server has changed everything). Boom. Video card hosed, and neither the kernel nor the X server have enough info to fix it... Cheers, __ \/ Andrew Apted [EMAIL PROTECTED]
Re: Win32 GGI
I think it's bad PR for the General Graphics Interface to split because it isn't general enough to handle win32 :). Besides, EMACS runs on win32 and didn't have to split, and if EMACS can do it, GGI can do it too! Marcus Sundberg [EMAIL PROTECTED] writes: John Fortin [EMAIL PROTECTED] writes: As alot of you probably know, I've been working on a Win32 port of GGI. A good portion is done, and I have been successful in getting XGGI to run on Win95/98/NT. The current GGI sources are very Linux oriented, as they should be. Huh? They aren't and they shouldn't. They aren't even UNIX oriented. Some targets and inputlibs contain code which are specific to the subsystems they are intended to drive, but that's natural. However, quite a bit of the source code is worthless for Win32 platforms. And it is not compiled on win32 either, so there is no problem. There are also places where there are just plain incompatibilities. select() for unix and win32 are very different, And I've already said that LibGII will be adapted for win32 as soon as someone with skills in win32 input handling tells us what we should use instead, or better still sends patches that implements it. win32 has no fork, fork() is not used for anything important. I'd like to propose the following A seperate project, WinGGI, and source tree based on the current GGI tree, devoted towards Win32 platforms. The basic libggi/ libgii api would stay the same. We really want win32 support and have wanted so for a long time, and well-written code which helps us achieve this will be included as soon as we receive it. We welcome any new developers, win32 hackers and others who want to help improve GGI code. There is absolutely no reason to have a separate source tree for win32. I would like to see some additions such as Joystick and sound support. There already is joystick support, and writing a joystick inputlib for win32 shouldn't be harder than any other inputlib. As for sound it is out of the scope of this project, but Wouter's LibGSI is already there if you want a nice sound library. //Marcus -- ---+ Marcus Sundberg| http://www.stacken.kth.se/~mackan Royal Institute of Technology | Phone: +46 707 295404 Stockholm, Sweden | E-Mail: [EMAIL PROTECTED] -- Shawn
