Hello,
I've commited the KGI target for libggi and the KII target for libgii into the ggi cvs repository. KGI target should be largely functional but there are a couple of features missing: Multibuffering: Currently only requests for a single frame will succeed. Eventually I'd like to be able to set the framebuffer offset to offer the user multiple frames. There are several issues that need to be resolved first. First of all there is no way of changing the framebuffer offset. I think that this should be done through some sort of a command interface. There is a SetOffset function in the framebuffer resource but it is my understanding that this is meant to be used for setting the offsets on paged framebuffers where only a part of the fb is available at a time. I suppose that some sort of OriginControl resource would do the job. Secondly there's the issue of how does one request more than one frame from KGI. Yes, there is a frames parameter in the kgi mode structure but think that it is meant to be used to describe the fb format only. That is the frames field would be set to two if the framebuffer contains two frames *interleaved* (AFAIK only SGIs are capable of that). Using the virtual fields is unacceptable as well because that would prevent the user from requesting several frames with virtual resolution larger than the visible one. One last possibility would be to use multiple images but I'm not exactly sure if that's what they were meant for. Color palettes: There is some code for setting the palette but it is not really functional. What isn't quite clear to me is whether the palette data format is supposed to be standard across drivers. It seems to me that it should, with 16bits per component, but I'd like somebody's confirmation of this. Also the cnt field needs to be standartized and graphic.c will need to be adjusted appropriately. The kgi target is meant to be the basis for further card specific sublibs and extension sublibs. My goal was to keep all the communication with kgi inside the kgi target and the sublibs would use interface provided by the kgi target. Currently the interface is quite trivial but seems to be sufficient for most cases. The kgi target provides a map_accel function which the sublibs can use to get their own private mapping of the card's accelerator (along with a private context). The header file also provides a couple of macros for easier use of the ping-pong buffer concept. I will commit the MACH64 driver soon as an example. For an example of use of the interface in a sublib of an extension you can take a look at the (work in progress) mach64 sublib for MesaGGI (yes, you heard right: hardware accelerated OpenGL) at http://www.student.math.uwaterloo.ca/~fspacek/mesa-mach64-020729.tar.bz2 the bulk of the code is in src/GGI/default/kgi/ATI/Mach64. Chunks are ripped out of the DRI driver and as I said it is work in progress but it is enough to run gears in hardware. As far as KII target goes that one needs a lot more work. If anybody who has a bit more knowledge of kii as well as gii wants to help out with this, I would be grateful. I'd appreciate if people tried out the kgi target and give me feedback about their success/failure. -Filip
