Re: Advice on Gouraud shading weirdnesses and testing
Rodolphe Ortalo wrote: My usual test program draws a few thousand random Gouraud shaded triangles on a 1024x768 16bpp framebuffer (5:6:5), using a 16bpp Z-buffer. Each triangle is defined by 3 vertices which are defined using the (Matrox-related) structs shown at the end of this mail. The WARP program (aka pipe) I use is a TGZ one, so specular, fog, and alpha color parameters theoretically have no effect on the drawing. Are corresponding units in the pixel shading pipeline disabled (e.g. it might not be enough to disable units setting up triangle parameters, but also those using (possible uninitialized) parameters...) Triangles get drawn correctly wrt x,y positions on the screen. However, The actual shading of the triangles is very strange. I usually get a *striped* rainbow color-gradient on all triangles. Changing the color of the vertices influences the shading, setting textures also affects the colors (but textures do not really show up yet). However, overall, it seems to me that the triangle drawing is wrong. (I expected to have a smooth transition on the triangle surface, not a striped result - but I'm not sure of what the drawing should be.) Do the frame buffer read out unit's and the shader's understanding of what the frame buffer layout should be match? (e.g. shader set to 555 weights and readout to 565 could give the above result). I am not very familiar with Gouraud shading, nor with the potential artifacts of this algorithm. (My test program more or less generates the vertices parameters randomly - so I guess it may really use the Gouraud algo. the ill way.) Initially, I thought it was a problem due to hardware setup (this is still a possibility and I'm pursuing efforts to check the driver) but well, maybe it is something else. Gouraud shading just means that color values are interpolated linearly over the triangle. Flat shading just dives it some constant color (either from the last vertex or from the average of all vertex colors). Phong shading interpolates the normals over the triangle and performs lighting calculation for each pixel. Does someone with experience debugging (hw-accelerated) 3D rendering can give me advice here? Are there situations where Gouraud shaded triangles renders to rainbow stripes? Or is it just the driver which is buggy (me very stupid sometimes :-). It looks as if there is an overflow in the color interpolation. Just try to set the triangles vertex colors to one basic color only but different intensity. This should result in a smooth gradient with only that color. May be this gives a hint where overflow takes place... teapot wanted I'd also really like to (re)use some classical 3D test programs and the associated tesselated 3D models in order to check the actual rendering of the G400. (If possible with reference output for various rendering parameters: with/without specular, with/without alpha, with/without textures, etc. And minimal porting work to reuse the code - ideally only the draw_triangle() function should need porting. :-) Do you know were I can find some? /teapot wanted I think the teapot thingy comes with the SGI sample implementation in the KGI repository. Steffen Seeger
Re: GGI and 3dlabs
Berlin Brown wrote: Would anybody know who I can talk to at 3d labs about their specification for the 3dlabs permedia 2. It is for a school research project I know it is implemented in KGI but I need something even lower level. Berlin Brown [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp What do you need it for? Have you already tried to contact customer support? -- Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: Lineo guy want to be involved in GGI/KGI (fwd)
Although I would like to demonstrate libggi with some pretty eye candy (just to show that the API is useful), the main issues I need to deal with are just proof of concept. (Pretty much what Steffen and the rest of the crew are working on already.) Basically 1.) compile something with KGI and see it run. Try the PhoeniX server. 2.) Speed comparison. 3.) perhaps run two apps that step on each other on normal frame buffer and show how resource management works in practice. I will try to get a little demo for this done. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: libGL/libGLX issue...
Steffen wrote: Hello, I just had the famous teapot demo going with the PhoeniX server with the SGI-GLX extension all running under kgi-0.9. This means that the GLX integration actually worked. So basically I can now commit the sources to the KGI repository and prepare for the next snapshot release. (Which basically means that I finally can get my hands on testing the kgi-0.9 acceleration framework :-)) However, I do have a question regarding the X/GLX libraries which affects the directory layout; so I need to sort this out before: The Mesa implementation merges the OpenGL library and the GLX library into libGL.so, so that only the "-lGL -lX11 -lXext" options need to be given to the linker. Is this the right thing to do? To answer my question: according to the Linux Standard Base and OpenGL ABI specifications it is. Steffen _______ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Happy New Millennium...
Hello all, a new millenium to everybody, and a little status update on what happened the last weeks. 1) There seem to be problems with source-forge after a recent system upgrade there. bash2 is crashing when generating the KGI-project websites, which might have caused you trouble accessing our pages during the last days. I have disabled automatic generation of the pages until this is sorted out. 2) I have finally managed to build a PhoeniX server with XAA. However, I still need to do testing and port the actual accelerator driver, but all in all the most difficult operation (transplanting XAA from XF4.0 into PhoeniX) seems to be finished successful. I will keep you uptodate, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: From Re: Video Memory to politics and Linus
"Jon M. Taylor" wrote: * Who will maintain KGI in the kernel? The current maintainers, plus other people who will see it distributed with the kernel sources and become a contributor in the grand free software tradition. That's the way it usually works. I should qualify this. Depending on volunteer labor would be unwise. However, a commercial entity would almost certainly come around to employing at least one KGI developer full-time to work on maintaining the system. _That's_ the way it usually works these days. So, anybody to hire me? ;)) Seriously, I think I will apply to some companies for getting paid for KGI development. At least when I go to Britain at the end of next year. My PhD is likely to be finished then, and I don't really have any concrete plans yet. May be, becoming a more clear long-term vision of my life... Greetings from the Cluster2000, Steffen _______ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: irc meeting about future of ggi
Tijs van Bakel wrote: Marcus Sundberg [EMAIL PROTECTED] writes: This weekend is bad for me. Weekend in two weeks is best I think. ok, that will be December 10th, 20:00 CET I'll try to be there, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: KGI / GGI architecture
Nicolas Souchu wrote: Could someone draw me a quit picture of the various KGI layers? You can find documentation of the currently developed kgi-0.9 architecure at the site mentioned (Articles section). Also what's the xterm stuff in the linux drivers? It's an sane implementation of a xterm-compatible terminal emulation for the Linux console. Mainly to have the linux specific extensions separated from the standard xterm behaviour. You mean that you have a big xterm (TERM=xterm) as your console? With scrollbar? TERM=xterm yes, mouse works as in TERM=xterm (except selections so far) yes, scrollbar no, but scrollback works as intended. (SHIFT-PgUp/PgDown). And textronix mode isn't implemented. Otherwise it works fine. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: KGI / GGI architecture
Nicolas Souchu wrote: On Tue, Nov 21, 2000 at 06:23:19PM +0100, Steffen Seeger wrote: libGGI should be portable to *BSD without the need for a KGI port. If, however, you are more interested in porting the KGI itself, get in contact with me. This is actually the way I'd like to proceed. As far as I could understand, everything should go very well once that done. But what would be your advice? Should I first port libggi on the FreeBSD framebuffer in order to understand its interfaces, or directly consider a port of KGI? I would port libGGI first, so you have all it's applications too. Done that I would tackle porting KGI-0.9. I would take that order because this is probably a more complicated task, because of the kernel hacking involved. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: irc meeting about future of ggi
Tijs van Bakel wrote: would anyone be interested in this? it seems best to use the openprojects irc network (http://openprojects.nu/) -- Tijs van Bakel, [EMAIL PROTECTED] If you let me know when and where, I will try to attend. -- Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: Video memory (Was: Re: GGIMesa updates)
"Jon M. Taylor" wrote: Antonio Campos wrote: 1) Installing KGI is not an easy task. (It only supports a few cards). _Running_ KGI is not an easy task, because it only supports a few cards. Installing it is actually pretty easy, unless you don't already know about kernel development issues in which case it would be _very_ difficult. KGI is not meant for the end user yet, although it is close than you might think. This is correct but also to some way intended. I have concentrated on getting the framework and concepts worked out, not to write as many drivers as possible. 2) It doesn't expose a way to handle 2D and 3D graphics in an unified (inside kernel) way. Yes, it does. Read the docs, please. To what I only like to add that they may be found at http://kgi.sourceforge.net ... 3) It doesn't handle the resource allocation of buffers (framebuffer memory (back and front, double and triple buffers, etc.), stencil buffers, and the like...) Yes, it does. Or rather, it provides support for resource allocation of abstract buffer types, and the individual KGI drivers themselves map out whatever buffers their hardware provides. It does handle mode specification and initialization of almost all buffer formats I know. Even more. You can specify z-buffered modes, whith/without alpha channels, overlays, stereo, anything you can think of. E.g. initialization of a double-buffered 16bpp stero mode with 16bit z-buffer works fine with the Permedia2 driver. However, splitting resources is not yet addressed by KGI-0.9, but is planned once I have an accelerated X server going. So, in that way we are in the right direction (though not yet really there where we want to go). Steffen _______ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: KGI / GGI architecture
Nicolas Souchu wrote: I'm a bit confused by the source layout and the KGI / GGI architecture. For exemple, what's the kgi directory in the GGI distribution? It contains an outdated version of the KGI implementation that works with libggi. Shortly after the stable libGGI release we decided to separate libGGI and KGI development, in order to have more frequent libGGI releases. The new KGI tree can be found at http://kgi.sourceforge.net (or www.kgi-project.org). Could someone draw me a quit picture of the various KGI layers? You can find documentation of the currently developed kgi-0.9 architecure at the site mentioned (Articles section). Also what's the xterm stuff in the linux drivers? It's an sane implementation of a xterm-compatible terminal emulation for the Linux console. Mainly to have the linux specific extensions separated from the standard xterm behaviour. Sorry, but the sources are not commented and since I'm not a Linux kernel expert I can't distinguish Linux from KGI interfaces. There are similar files in kgi-0.9, located in linux/drivers/kgi in the patched kernel. These implement a full reimplementation of a console subsystem, which now also official kernel develoers have accepted to be neccessary. However, as KGI development started, it was just broken and we had to do a sane console implementation first. The problem was mainly that you have to coordinate who is accessing which hardware, and the console driver, SVGAlib and XFree86 are happily competing for concurent access... I would have imagined something much more light from the KGI point of view. So would have I, but the console code in Linux was just crap. The linuxconsole project attempts to address some of the issues, but does not do this consequently enough, in my opinion. libGGI should be portable to *BSD without the need for a KGI port. If, however, you are more interested in porting the KGI itself, get in contact with me. Yours, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: one linux box, multiple X users
Andreas Beck wrote: Since Linux supports multiple keyboards, mice and graphic cards it should be possible to have one computer on which different people can work on simultaneously. Yes, though it is a bit tricky. It's quite some work before that becomes possible. I have tried to ge such a machine running with kgi-0.9 and even had some success as far as console work was concerned. Getting two graphical sessions going was a quite difficult. It worked in the end somehow (even with XF86) but was not in a very useable state. Mainly because the XF86 server thought it should initialize all video cards it finds... The problem are the mulitple keyboards. How can I assign them to a X server? For XF, AFAIK this isn't possible. Using the KGI-0.9 code I have had such a machine with two independent sessions going. However, only one could have been graphical. The among some initialization issues popping up with XFree 4.0 there were mainly problems with the console (device) permissions which require work. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: Video memory
Lee Brown wrote: On Tue, 07 Nov 2000, Christoph Egger wrote: Thank you for responding to my original request. As a result I read a little on RRM. You have clever friends. This idea of multiplexing the graphics registers is interesting. I guess you would have to put graphics context into the task struct in order for it to work. When the kernel switches tasks, not only does it set the cpu registers it sets the graphics registers too. Or something like that. I doubt, that Linus will accept that in this way, because that slows down the task-switching rapidly... I thought of this too. Does it? I mean it's just a few more registers to reset (on top of the CPU registers). Yes, for a decent 3D card a minimum of 200 to 300 registers, to be read out and set over the PCI bus... This is the simple but not really scalable approach. You have to avoid graphics context switches whenever possible, and this is what the /dev/graphics mapper in kgi-0.9 tries to accomplish. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: Video memory
Lee Brown wrote: On Mon, 06 Nov 2000, Christoph Egger wrote: It seems, that the time comes, where KGI can go into the kernel, no? I am still not sure under what conditions Linus would accept KGI. I mean does he have to take it ASIS or can he make a laundry list of requirements and have KGI make the neccessary changes? Just a list of requirements what is so bad about it would be something a civilized discussion could start on. So far I have only heard that he would not accept it, but no acceptable reasons why. This requires he has a look at it, but I doubt he will given that DRI seems to fit his 'needs'. I say this because after reading the kernel mailing list I get the idea that Linus has very specific ideas about what he likes and doesn't like in the kernel. I hope he is, but this seems to have a certain shift in time... Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: Video memory
Lee Brown wrote: It seems, that the time comes, where KGI can go into the kernel, no? Would Linus have to take KGI ASIS or are the terms negotiable? There are quite some terms negotiable, but not the main goals of KGI: portable graphics drivers, possibility of high security and high performance implementations, independence of the windowing system. As far as I have understood Linus, he wants everything 'for Linu X only', and this is contradictonary to some goals of KGI. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: Porting to PowerPC
Paolo Scaffardi wrote: i am developing on a PowerPC embedded processor (MPC823) and i want to run an X-server on its video-controller that can handle YCbYCr data format (4:2:2) in memory. It simply stores 2 bytes per pixel, depending of even of odd position, YCb or YCr. I ported GGI and XGGI on my board, but the problem is that XGGI doesnt use GGI primitives, but its directbuffer feature, that permit the program access directly to the memory buffer that it supposes to be a RGB framebuffer, not YCbYCr. I heard of KGI and its PhoeniX X11 but i dont know how they works togheter and if they access directly to the memory or if they use other library primitives. Have you any hint for me? The only chance is probably to use the YCbYCr buffer as a direct color buffer (fixed pixel value to color mapping) and use a translation table/function to convert RGB into palette values. Also you will probably only be able to use half the resolution in x-direction, as the color values are shared among two neighbouring pixels. Another method could be to have a shadow buffer (rgb) and translate it into YCbYCr when blitting it to the screen. The memory visual of libGGI/XGGI does probably allow for this, at least it could probably be modified to do so. However, PhoeniX so far works only with 8bbp, and needs at least the pallette setting implemented. I would not recommend it for your application if you need to get it going quickly. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
kgi-0.9-20001011 snapshot
Hello all, it took it's time, but here it is, the new snapshot of the kgi-0.9 source tree, now featuring - a /dev/event mapper implementation - a semiworking X server (not yet accelerated, but I am working on it). - an improved Display DDK documentation. Have fun, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: KGI documentation
Lee Brown wrote: Steffen, Here is the finished product of my little introduction to kernel graphics. The documentation comes in multiple forms: HTML PS texinfo DocBook It was written in texinfo. I used texinfo 2 DocBook to get the SGML version. BTW if anyone is interested in converting texinfo to DocBook I have the software. Comments? Thank You, Lee -- Got it and will be reading through it. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: Where is the GGI project heading?
Andreas Beck wrote: I mean, is there any schedule on when a new release of GGI/KGI is going to happen? Hmm - Marcus: How is your current schedule ? We should probably finally whip up a new LibGGI release. * Is going KGI to be integrated in the new 2.4x kernel series? No. If not, why? Hmm - Steffen what is your status ? Current status is that I returned from a badly needed holiday, finding that the important threads always happen when I am away. Still working, or did you quit ? Still working. I am currently getting a light-weight X server running with KGI-0.9, which is currently initializing the graphics card and displaying the windows. I am right now implementing the event delivery in KGI-0.9 and getting the X server to respond to my input. Then there will be another snapshot release. and should the GGI team develop a branch of the kernel? If someone wants to do this, it might make sense. We maintained patches for a long time a long while ago, but as noone seemed to be too interested, we started lagging behind kernel changes and finally stopped updating stuff. KGI-0.9 will follow Why doesn't Linus want KGI inside the kernel sources?. The data about this topic is very dated. I wouldn't count on that still being the case, with stuff like DRI also getting its helper modules in. That's a question Linus has to answer, not I. And DRI? Is DRI possible under GGI? Noone has tried yet. According to Steffen DRI is something one shouldn't really try ... You could try it, it might work, but I cannot recommend it for everyday use, as any user running a DRI program can accidentally freeze the machine, just by halting the program in question at a bad time. See the security analysis at PI's website. Is GGI/KGI ending as a curiosity - another kind of graphics library - , I am afraid it will - regarding Linux. Which is my feeling too. However, as long as there is no solution to the problems I intend to solve with KGI, I will continue with it. Maybe someone can use it too. Jon M. Taylor wrote: *BSD has been ascendant recently. There have been discussions in the past about using *BSD instead of Linux as the primary KGI development OS, but nothing ever happened. HURD was also mentioned at one point, as was Win32(!). This is still on my list of cool things to do, and recent developments have only made me more certain about that. There is, however, one point that keeps me from immediately jumping at HURD/Mach, or other OSes: I want to have the concepts for the driver model _working_ and fleshed out before ports to another platform start. As a beginning, I would love to see the current KGI-0.9 running on PPC or Alpha, but I have no hardware to test it, nor are there developers having the hardware and wanting to do the port. Once the KGI-0.9 acceleration concept is proved, we can focus on taking the world, doing it before will cause a bigger mess than worth the hassle. * I never got the 2.3/2.4 port working. Close (it wasn't _that_ difficult), but no cigar. The 2.2 kernel series is still being actively maintained by Alan Cox, but 2.4 will have several new features (most notably kiobufs and devfs) which if used by KGI would make the KGI kernel patches quite a bit smaller and simpler. Intentionally I do not put work into a 2.4 port before 2.4-final is out. Mainly because then is clear what parts of the new console system are in. For the current stuff I am working on, 2.4 is not a requirement, so its not on the priority list. In sum, while KGI does require a decent bit of work, it is already quite far along. Oh yes, it is. Though it needs work. Fortunately I will find the time to give it another push during the next two weeks. Don't give up on it. It's hard some times, but I've quite a high frustration level... But even that gets exceeded sometimes. If you don't already know about how kick-ass Steffen's design for the new KGI is, or haven't read Steffen's excellent architectural descriptions of KGI, please head over to SourceForge and do some KGI browsing. You'll be amazed. Thanks for the credits :-) Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: new GNU libxmi released
"Jon M. Taylor" wrote: On Mon, 10 Jul 2000, Steffen Seeger wrote: "Robert S. Maier" wrote: Hi, Jon and other GGI folks. I haven't been sending anything to your list (I've just been lurking), but being the maintainer of GNU libxmi, I thought I ought to do so now. So you (and Jon) might be the right people to ask this question: Does libXMI work out of the box as an replacement to the MI code in the X11R6.4 sample implementation (with XFree enhancements)? Out of the box? No, for the simple reason that I had to modify the API calls to take an additional ggi_visual_t pointer as their first argument. I have also altered the miPixmap datatype and removed the miBitmap datatype. The majority of the rest remains the same, though. I am asking because now that I have the PhoeniX framework in CVS and compiling, I wanted to add a DDX driver t for a simple framebuffer X on kgi-0.9. The thing I was wondering about was if I could use libXMI as a mi replacement for PhoeniX, and investing into an accelerated libXMI. However, so far it looks as if I stick with my plan on getting XAA running. Any suggestions/comments? Steffen _______ Steffen Seeger mailto:[EMAIL PROTECTED] TU-Chemnitz http://www.tu-chemnitz.de/~sse
Re: Kgicon - Many questions, any answers ?
Christoph Egger wrote: XGGI: Just wanted to know whether there is still active developement. Well, it seems to me, that all XGGI-stuff is now done by Steffen. Not 100% correct. PhoeniX is for now intended as an _experimental_ project-internal server to have something to play with KGI-0.9. It's an X11R6.4 server based on the XFree-4.0 distribution, but not relying on XFree-4.0 device dependent (ddx) code. It's just the server cut out of the XF40 distribution, in order to reduce build time considerably. XGGI development is still in the trustworthy hands of Marcus, who is, however busy with libGGI development at the moment. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: SVGALIB4ggi
Andreas Beck wrote: I tried several times last week to subscribe to various ggi/kgi mailing lists without sucess Hmm - most of the kludge.org stuff seems dead - but it isn't used much anyway. Please try the [EMAIL PROTECTED] . The KGI mailing lists have been moved to SourceForge, detailed instructions which mails are availabe and how to subscribe can be found at http://kgi.sourceforge.net/developers/resources/welcome.en.html#mailing-lists Steffen PS: Is the kludge.org mailing list maintainer still around? ___ Steffen Seeger mailto:[EMAIL PROTECTED]
kgi-0.9-20000418
Hello, a new snapshot of KGI-0.9 has been released and may be downloaded from http://kgi.sourceforge.net What's new? - Overall source tree cleanup - source tree now moved to SourceForge's CVS Repository - added driver development SDK (basically a few scripts that aid you in getting a driver framework started easily) - added TI TVP3026 ramdac driver (which was created using the SDK within a day). - it all compiles again except for the X server. Enjoy trying it, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
new KGI mailing lists
Hello everyone, the KGI mailing lists are operational at sourceforge: [EMAIL PROTECTED] If you have comments, suggestions or technical questions about software developed by the KGI Project this list is the one to subscribe to. If you want to participate in the development of KGI, the kgi-develop list is one you should be subscribed to. Subscription info can be found at http://lists.sourceforge.net/mailman/listinfo/kgi-develop [EMAIL PROTECTED] If you are interested in the development of the KGI Project, but don't want to know the details, this list is the one you should subscribe to. kgi-announce is intended for general announcements regarding the Kernel Graphics Interface Project, such as snapshot releases, news of public interest etc. It therefore should be rather low-traffic. Subscription info can be found at http://lists.sourceforge.net/mailman/listinfo/kgi-announce [EMAIL PROTECTED] If you have problems installing and using software from the KGI Project or want to discuss general issues or your experience with other users, you may direct your questions to this list. Subscription info can be found at http://lists.sourceforge.net/mailman/listinfo/kgi-users I would like to ask anyone subscribed to [EMAIL PROTECTED] to move over to the new lists now. I will stay subscribed and crosspost to [EMAIL PROTECTED] for about two months but main activity will be on the SourceForge lists from now on. I am sorry for this inconvenience, but it appears to be better to move now than later. Yours, Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: moving KGI to Sourceforge
Thanks to everyone for their support. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: moving KGI to Sourceforge
Andrew Apted wrote: Steffen Seeger writes: I have created a sourceforge account to host KGI related resources in one central point. There is a web-page available at http://kgi.sourceforge.net/ What is the license on KGI-0.9 ? None of the files in the 2000-02-22 version contain any license info, except for something nasty looking in the nVidia source, and the files COPYING.[L]GPL in the config directory. The core and all drivers I have copyright of will be under MIT/X style license. The sample implementations (for Linux so far) will be just as the target requires. KGI used to be under the GPL (IIRC), The Linux sample implementation, yes. However, if you need a different copyright for parts I have written, just ask me what for. perhaps now KGI will be under an Xfree style license like LibGGI ? As said above, KGI itself will/is MIT/X (I am just going through the files before moving the CVS-Repository to SourceForge and add a copyright notice stating it is under MIT/X license where appropriate. That's what we agreed on at the last copyright debate. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
moving KGI to Sourceforge
Hello all, I have created a sourceforge account to host KGI related resources in one central point. There is a web-page available at http://kgi.sourceforge.net/ with some of the articles I have written about KGI in the past. New ones, will follow, especially driver development guides and API specifications. For now I will try to get the resources and infrastructure set up. Attention driver developers (Jon, Johan, Jos, ...): Please get your own source-forge account (preferably lastname_firstname initial) and send me the neccessary info so I can add you to the developers list. Some misc points: 0) I still had some trouble getting developer access for CVS to work. As soon as I resolved this, I will put my CVS tree up on Sourceforge. 1) I would like to have the KGI mailing list moved (for the last time hopefully) to sourceforge as long as it is low-traffic and not very widespread. Can we set up the old list such that it sends a 'this list has moved, please subscribe to ...' message to new subscribers? That's all for today, updates will follow. Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: introductory architecture questions ?
Hi Jon, you wrote: I am interested in security and microkernels, so GGI appeals to me because I like the idea of small kernel modules that securely multiplex graphics. However I have some concerns I was not able to answer from the online documentation. Firstly, more architectural diagrams please ... I searched and read lots of pages on GGI before I found Peter Amstutz's diagrams in the 'OLD' documents section. I found they helped, almost as much as everything else I read put together. I think it might help other interested people if architectural diagrams occurred up front in an introduction document, then readers know which bits they want to read about. In particular the FAQ compares GGI to X, to SVGAlib, window managers etc. Several of these are obviously bogus comparisons (as the FAQ points out) but I think a couple of diagrams would clear this up much better. [ 4 in particular: GGI, X, SVGAlib, and GGI on X on GGI ] I will take these valid suggestions into account for the new documentation I am writing at the moment. The obvious missing comparison was Plan 9's 8.5 which securely virtualises devices. Could you perhaps give me some pointers to information about Plan9? I am not a OS-researcher (yet) but doing physics. All I know about OS/driver design is what read/learned myself. And a couple of security questions. [ Please assume a system in which multiple processes of the same user may have different security domains ] 1) Can two GGI programs securely share a display ? This depends on the target I would say. If the target supports proper virtualization and protection (e.g. a secure X11-like protocol that checks permissions before performing graphics operations) it could definately be. The problem I see more is how to impose that security without drastic performance loss. That's what the KGI portion is supposed to help with. Presumably each would have a device whose virtual display was a portion of the physical display. This is much like KGI-0.9 is working internally. The graphics driver exports so-called resources, that e.g. may be a memory region, a accelerator FIFO, etc. which then is mapped to the application. The application thereby opens a device (virtual display) and requests to map resources into it's address space. However, its up to the hardware, the driver and the mapper to enforce proper isolation and protection. I have not yet seen any hardware that was designed to meet these goals under the constraint of decent performance. 1b) If two programs securely share a display, do they do so by giving up hardware acceleration ? How do you define the term 'securely'? 2) Can I implement a feature like the WinNT logon dialog that comes up in response to the three fingered salute ? In security parlance a trusted-path: a user can trust the dialog that comes up in response to ctrl-alt-delete because a) kernel catches ctrl-alt-delete before any programs, and b) no programs can access the window list associated with the login dialog. Doesn't do pressing CTRL-ALT-BACKSPACE at the XDM prompt something simuilar? Because I don't really have a good grasp on the architecture its possible Im not asking the right questions ... TIA - JonT I am currently (re-)writing the documentation for KGI-0.9 which is mainly about such issues. I would be happy if you could attempt to read through them and give some comments on both the docs and KGI in general. Do you have any time constraints to be met? Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: kgi-0.9-20000222
Rubén wrote: 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? I have added (untested) acceleration handling code to the Permedia2 driver in the previous release. I am currently busy at work/my phd, so I had no chance to test it. However, acceleration handling will be done in the chipset driver, there will be no separate module. - added S3 ViRGE driver framework by Jos Hulzink Cool! Beware it's a framework, it doesn't do anything yet as far as I can tell without the hardware. [ GGL developer ] [ IRCore developer ] [ GPUL member ] You still get your code snap from my OpenGL experiments... Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
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
James Simmons wrote in respone to Jason McMullan: BTW: Was there _anyone_ other than I that cared about GGI Console enough to try the code what I was developing it? Yes. Yes, Jason, there were. And it worked for me. If there's a desire, I would love to work with the FBdev team to get more GGI Console type structure into the kernel, at least on the display side. The same for me. Multihead systems are planned for 2.5.X. So far the people involved in the design of the new console system are Vojtech Pavlik, myself, and Geert Uytterhoeven. Others are welcomed. Matrin Mares was invloved in the new design but due to limitations in time he placed me in charge of the developement of the new console system. Unfortunely I have the same problem. Developement will pcik up once 2.4.X comes out. Vojtech has worked on the input system based on GGI consoles input system and has quite a bit done. I have worked with Geert to prepare fbdev for real multihead support. Some still needs to be done. The core part the console system itself needs a really work over. This part is really vaporware. Both me and Matrin Mares have some early code which is in the input patch. Of course this wasn't completed since me and Mares disagree on several design issues. What needs to be done? Well both me and Vojtech have early work for multihead support in 2.3.X. Vojtech already has /dev/event in the usb directory of the developement branch. I have slowly been placing a new fbdev API in place. Many drivers have not been converted over to this new API. I need those drivers ported over and I can't do it alone. What I have learned which will heavly influence the design of the console system. That the driver for the raw hardware does NOT need to know anything about the console system. Fbdev is heading in this direction. The fbdev driver will have no console code what so ever in the near future. It will be fbcon.c that will provide the abstarction layer to the console system alone. This provides the ability to have fbdev and vgacon run together and lots of other nice features. The same will go for the input drivers. Fine. Jason and Steffen since you have attempted multiheaded support before your input will be greatly welcomed : If we all work together we can come up with one heck of a solution. This is going to be my project at 3Dfx. It's going to kick butt to have quake run on multiple heads of course with several voodoo cards. Sure, but this requires you have some people you may put your input into and that that some people need to care what you say. From what I understand your statements above, the effort so far has been private conversation between Vojtech Pavlik, myself, and Geert Uytterhoeven. KGI has been open since it's beginning, is open, and remains open to anyone willing to contribute. Steffen ___ The difference between a "concept" and a "random collection of routines" is that the concept will survive, and the routines won't. -- L.Torvalds _______ Steffen Seeger mailto:[EMAIL PROTECTED]
Re: evstack
Steffen Seeger wrote: From what I understand your statements above, the effort so far has been private conversation between Vojtech Pavlik, myself, and Geert Uytterhoeven. Ooops. Don't cut paste ^^ - yourself ;) Steffen ___ Steffen Seeger mailto:[EMAIL PROTECTED]
mailing list archives broken
Hi, the mailing list archives on www.ggi-project.org seem to be broken (no messages since September 1999. Steffen - e-mail: [EMAIL PROTECTED] -
Re: SGI OpenGL freely avalibale.
On Wed, Jan 26, 2000 at 04:42:38PM -0500, James A Simmons wrote: http://oss.sgi.com/projects/ogl-sample/ What's missing from the current Sample Implementation? Dynamic assembly code generation for rasterization is not yet included, making software rendering performance slow. Interesting, we came about the same technique as SGI: The GGL code in KGI-0.9 was a code-study how to dynamically generate i386 assembly code for software rasterization. Steffen - e-mail: [EMAIL PROTECTED] -
Re: KGI-0.9 stuff
On Sat, Jan 15, 2000 at 01:32:12PM -0800, Jon M. Taylor wrote: I will be working on a jmt3 release this weekend, so if anyone out there has outstanding patches and wants them merged into jmt3, get them to my by midnight PST. Jos, I have your latest ViRGE patches which you posted to thie list. Brian, I will be working on the VGA driver again this weekend, so if you have made any useful changes since jmt2, please let me know OK? The goal is to get the VGA driver to set one or more textmodes, as well as 320x200x8 and 640x480x4 modes. This will be plenty to write and test a LibGGI target against. So I will start my merge from jmt3. Please send me your jmt3 tarball as soon as it is ready, and I will prepare the next official KGI-0.9 release starting from it. Steffen
Re: CT65555
I've contacted to author of the CT driver. He told me that it is 2years old sources. So I have no idea now where can I get driver. Worst case will be writing a driver by myself. But I have no time at all :(. Dmitry I have a CT 6 in my laptop I planned to support once the P2 driver is reasonably finished (accelerated X). But this is some time away. Steffen - e-mail: [EMAIL PROTECTED] -
Re: DirectX
Also can libGGI handle DMA transfers, AGP? That's handled by KGI/the drivers respectively. The Permedia2 driver has a first pre-alpha version of accelerator handling for KGI-0.9 from the driver side, but this code is not yet complete (about 95%). And it needs testing, of course. However, in theory it should be able to handle an 'unlimited' number of independent graphics command streams, fully virtualized and decoupled from applications. AGP support is under construction, with a code study of a AGP 'miniport' driver so far. However, I will first need to have the Permedia2 accelerator code running, before AGP becomes an issue. Steffen - e-mail: [EMAIL PROTECTED] -
A question on wait queues...
Hello, I have started to debug the accelerator mapping code. It has a bug I suspect to have it's origin in wrong useage of wait queues. Can someone give some hints or pointers where to find information about the intended use of wait_queue_t is in 2.2 and 2.3 kernels, and what are the differences between 2.2 and 2.3? I have a good documentation about the 2.0 wait queues, but this info seems rather outdated. Thanks a lot, Steffen - e-mail: [EMAIL PROTECTED] -
Re: More Gx00 code for those truely insane.
* Don't use pcicfg space for other purposes than initial configuration. Especially do not use it in _mode_setup() to distinguish device versions. Use flags or a chipset_version field in the meta_t structure instead. A question on this. Is it sugested that I detect the vendor/device id and revision once in the chipset bind code only, and then somehow share that data with the ramdac and clock code, or should I probe this in every meta driver? Neither nor. vendor/device id and revision should be probed in the chipset binding driver and the ramdac binding driver if it is an integrated ramdac. All code in the binding driver has to 'bind' the meta driver to a particular instance of the device(s) handled by the meta driver. Therefore it has to do detection and verification. Chipset drivers must verify the vendor/device ID and ramdac drivers should do this, if the chipset driver may serve at least one device that does not have this ramdac fitted. In this specific case, I also need to know the RAM type, since the cards clock capabilities vary from RAM type to RAM type. Can you give some more details on this? How do the clock capabilties vary between the RAM types? If it only affects the RAM bandwidth, or LCLK limits, this can safely be handled in the chipset drivers. now I have this implemented as a flag in _chipset_t, but I'm not aware of how to share this with the other sections, like the GET_PRIVATE does in KGIcon. Not at all. Each driver should not make assumptions about others, except where a kgim_ metalanguage type (e.g. kgim_monitor_mode_t) is defined. This requires some proper thought, but should be possible. Steffen - e-mail: [EMAIL PROTECTED] -
Re: More Gx00 code for those truely insane.
Hello Johan,
the Degas code however, is on a sorry state of disrepair, It's still missing
big parts of functionality and is so riddled with #warning and #error
statement that even thinking of compiling it would be a waste of time.
however, if somebody is interested in looking it over, feel free to do so.
Some comments from a really insane...
* all symbols visible with 'nm objectfile.o' should be prefixed with
the metalanguage prefix.
* Don't use pcicfg space for other purposes than initial configuration.
Especially do not use it in _mode_setup() to distinguish device versions.
Use flags or a chipset_version field in the meta_t structure instead.
* calc_partials() is a "permedianism". The Permedia can only accelerate
frame buffers with certain widths. calc_partials() calculates the next
supported width.
* bpd, bpf, bpc and bpp refer to the number of bits per
{d}ot (unit transfered to the dot port)
{f}rame (unit stored per pixel and frame)
{c}ommon(unit stored common to all frames)
{p}ixel = bpc + (stereo ? 2 : 1) * frames * bpf
* Drivers must not share region information. E.g. you must not give the
DAC driver access to the memory control region claimed by the chipset
driver except through the DacOut() functions. If you have to access
indexed registers, declare a 'static inline' function in the
ramdac/clock driver.
* The kgi/ directory is reserved for kgi extension headers.
Chipset register declarations should go to chipset/Matrox/Gx00.h in your
case. This has the benefit you have them at hand where you work the
most time.
* I found it useful to convert the header to the naming conventions first.
Especially as this gives a good overview what registers do what.
These are the comments that came to mind when I had a quick glance over it
yesterday. Keep asking/working on it!
Thanks,
Steffen
- e-mail: [EMAIL PROTECTED] -
Re: Multiple users
Works great with all four buttons and the wheel. As of kernel 2.3.25 the USB mouse driver only supports one USB mouse, ARGL ... will they make the same mistakes again over and over ? Yes :( The good news is Vojetch is working on something that does use multiple mice. Even regualr mice. I can only make suggestions, but he should have a look at using KGI-0.9 as a base and simply enhance the somewhat neglected KII input interface a bit. Thanks Brian there is a patch that allows the input interface to be used with kgi-0.9. but if none of the USB people does it before me I intend to fix that. Good. TNX. As for keyboards it seems you can attach multiple USB keyboards, but everything will go into the normal (single-headed) console system via calls to handle_scancode(), so multiple keyboards are pretty useless. Ouch ... Vojetch is also working on that :) Last time I tried it I got two ps/2 keyboards to work (one was in my ps/2 mouse port). No comment. Thanks Brian there is a patch that allows the input interface to be used with kgi-0.9. If you manage to get the input drivers by Vojtech working with KGI-0.9 for multiple USB keyboards, you are ready to go multihead! Even without KGI-0.9 drivers... I intend to hack the USB keyboard driver to export a character device per keyboard, supporting medium-raw mode and the normal keyboard LED ioctl()s. If the USB people doesn't like that I'll maintain a separate patch. Take a look at Vojetch work. ftp://ftp://atrey.karlin.mff.cuni.cz/pub/linux/input I would be very grateful if his work could be used with KGI without having to rewrite it again. Hmm - I'd rather just export an event oriented interface and handle dispatching in userspace ... greetings from EvStack, you know ... :-). By the way Vojetch work is based on GGI console. I am not clear what you referring to here... EvStack? ggi-0.0.9? kgi-0.9? He thinks it was really good work. The only real difference is its less streams orientated. Linus hates ATT Streams for some reason :( Or other three-letter words... Vojetch is working on the keyboard part and I'm working on fbcon so we can have a true multiheaded system. Note also the newest 2.3.x kernels have real resource management now. Its being worked on for other types of buses. So linux is finally evolving to the KGI level. Good to hear. Steffen - e-mail: [EMAIL PROTECTED] -
Re: tested KGI 19991017 snapshot
Just tested kgi 19991017 snapshot on a fresh 2.2.10 kernel. All I could test was a textmode IBM VGA driver. Everything is rocksteady! Thank you for testing. Well, there are some known bugs, but all in all it's quite useable. A few 'bugs' that are not in the documentation: - keyboard in svgalib programs does not work (probably because of the RAW mode it operates in) Mhmm... X operates in in RAW mode too... Could perhaps investiage this further? I don't have a chance to test svgalib (unsupported chipsets). - when killing an svgalib program and switching consoles, almost simultaneously, the screen goes black; it could be restored by switching to x11 and back Does this occur with a standard-kernel too? If not, it is a KGI bug, if so, it is a feature. Showing that the emulation is able to produce the same bugs. - alt-f? work in X11 too, where one would expect them to be ctrl-alt-f?; this is probably hard to fix - Yes and no. We just have to deny console requests if the keyboard device is in graphics/raw mode. A fix I would like to suggest is to use CTRL-ALT-F? for console switching too. When/how will I be able to use libggi on kgi again? When the drivers are operational again. The Permedia2 driver works quite reasonably, at least setting modes and exporting the framebuffers. However, there is still some work to be done so that it can take over a running board safely. Is there some place I can hack on a graphic mode for ibm vga? Yes. 1) The fixed clock driver needs to be ported. 2) The following drivers need to be written: chipset/IBM/VGA-meta.c chipset/IBM/VGA-bind.c ramdac/IBM/VGA.h ramdac/IBM/VGA-meta.c ramdac/IBM/VGA-bind.c (the source tree is, even after reading the docs over and over and over again, very hard to understand..) I couldn't make out if there was graphic support for ibm vga _at all_. No there isn't. The concept behind the 'difficult' layout is actually simple, but not yet documented. For each piece of hardware, there is a 'driver'. Each driver consists of a register definition (.h), a 'meta-language' part (-meta.h) that implements the features of that piece of hardware (e.g. how to set a video mode, what modes are possible, mode checking, ...) and a 'binding part' that implements the hardware detection and access stuff. So, you would have to write a driver for the VGA, just to support graphics modes (for text modes, just fall back to the VGA-text driver, as the PERMEDIA driver does). There is virtually no documentation, but also not yet a fully working driver to document. Sorry, but getting the driver running is #1 priority at the moment. All in all, it's gotten a lot more usable! Great work. -- Tijs van Bakel, [EMAIL PROTECTED] Steffen - e-mail: [EMAIL PROTECTED] -
Re: RFD: KGI(con) speed optimization
Hi
Working on my ViRGE driver, I noticed something:
Handling the KGI commands, most drivers use a switch () {case ...}
structure. This looks nice, but results in very slow code (each case
results in at least one conditional jump, which can slow down the CPU
badly)
I was wondering: Using a procedure lookup table would improve the speed a
lot, but would require that I can take the definitions in kgi_commands.h
as static ones. It would result in code like (this is no real code,
only to make things clear)
int * accelleration_command[](void *, struct kgi_display)= {
ViRGE_2D_DrawLine, /* This depends on kgi_commands.h */
ViRGE_2D_DrawBox,
... etc...
}
(*accelleration_command[_IOC_NR(cmd)])(gr-io_buf,gr-dev.dpy);
instead of :
switch (cmd) {
case ACCEL_DRAW_LINE:
case
case
}
Notes here: _IOC_NR is Linux only and must be replaced by a KGI defined
compatible function. I use _IOC_NR to get values in the range 0-255,
otherwise the table would become very huge with many unused entries.
Comments please...
Jos
AFAIK GNU C does that if it becomes faster. So, it depends on the compiler
you use :-)
Steffen
- e-mail: [EMAIL PROTECTED] -
