From: Steve Cheng To: linux-ggi@eskimo.com Subject: IRC session summary Please note any mistakes or if I left out any relevant parts. Most of it is copied out speech, but anyway... ******************************************** Summary of IRC Session About the GGI Project ******************************************** KGI Drivers =========== Emmanuel Marty has committed sources to the MediaGX driver. There is a good chance that Steffan Seeger will start work on a driver for the 3Dlabs Permedia (2???). He has to sign an NDA, though at this point it is unclear whether or not the source to the driver can be released. Steffan would like to change KGI initialization a little bit to handle the several layouts for one depth. Code Fixes ========== According to Steffan, the TVP driver does not work with S3 968. He is into it, and hopes he can fix it tomorrow. The MediaGX driver still has some caveats. Emmanuel will try to fix most of them before Monday evening. Estimated 80% - 90% complete for Dali release. The infamous XGGI mouse-handling bug has been fixed by a patch. It was caused by PS2AUX driver. Documentation ============= Most of the "necessary" parts of the LibGGI documentation is already done. Some people plan to look over it. It can be found at: DirectBuffer documentation needs some minor updating. Steffan Seeger will have a look at driver documentation. It is outdated, but will have to be redone for EvStack anyway. Manpages for Degas. Distributions and Release date ============================== The final release date for Dali (a.k.a. GGI 0.0.9) was postponed to 31st December, 1997. Reasons cited: * Steffan Seeger wanted to have more time for testing KGI * Tree needs to be cleaned up, miscellaneous README have to be written, etc. * RPM, DEB, non-Linux distributions. They are not crucial, and will probably be late even if the date was not postponed, but some extra time is beneficial. Degas (next version of GGI) Configuration Scheme ================================================ The whole thing is kept as modular as possible. Best is to describe the install process as the user sees it: First you will checkout (either by tar, or by cvs) a source tree. E.g. the whole ggi sources, or only a part of it, like libGGI, or libGGL, or the KGI drivers/patches. If you checkout only a part, let's say all libraries in lib, you have to change into this directory and checkout the 'config' directory too. e.g. like cvs checkout lib; cd lib; checkout config One goal is to have totally independent parts. However, there might be dependencies on certain parts being installed before the others can be build. Ok, now when you type make in the lib/ dir, GNUmake will find the Makefile first and the default target is a config/configure. This is why you need the config package in the toplevel directory of the checked out tree. configure will first examine the system, and create a .config file with several variables set. Then it will create a link to the GNUmakefile in config/common which contains the recursion programs. Then it looks for subdirs with a .configure file and changes over to each subdir found. In there it creates the links for the GNUmakefile, and for the .config file. If .configure is executable, it will be run. This local .configure may override or extend the global configuration by creating a .config.tmp file that will be the target for all .config links in further subdirectories. So you can override things localy. So, the toplevel configure will recurse the tree and create the links. After that, you simply type make another time (or it is done automatically), and it goes for the default target. This is to make the local default, and the default in all subdirs that have a GNUmakefile. By default, the implicit rules in GNUmake.gcc will create the dependencies (..d) and then build the object files. All you need to do is to list the object files in the Makefile as dependencies of the default target. Also, it will know about preprocessing, doing assembly files etc. If you want a subdirectory be excluded from this, go to the subdir and do a make distclean, which will remove all the links in the subdirs. Also, dependencies will be updated automatically, just no worries about what has been changed. If you like make being verbose, type 'make' if you like it silent, make an alias 'make -s'. So, all will be happy :) So, the whole point is to have all machine specific stuff in config, and only the 'what needs to be build' info in the Makefiles. /* There are no plans yet on how these configuration executables should look like, though they might be sh scripts. */ Evstack will include KGI configuration into the normal kernel config. Autoconfig ========== Andreas Beck (Mr. Macarena ;) recently added PCI detection to the autoconfig. We can probably shrink down the card-ID type entries quite a bit. No significant problems with autoconfig at this moment. BPP emulation Pseudotarget ========================== A need was identified for the ability to run palettized 8 bit modes on a non-8-bit-color device. The plan is for it to be solved by a LibGGI pseudotarget in the Degas release. It may be implemented by improving the current LibGGI multi-target. There will be performance problems with BPP emulation, but having it work slower is better than not working at all. EvStack ======= EvStack keeps up with the current kernel always and will require a 2.1.x kernel due to the /proc things in there. Current version is 2.1.72; will catch up to 2.1.74. EvStack means basically we go from calling functions to distributing messages or rather events. We do this by some efficient method which will not suffer from the performance penaly things like streams have. The EvStacks basically make up a flow of events which tie together the pieces and two nicely uniform APIs that allow for consistent programming of all kinds of drivers. Two APIs ? Yes - two. One via the events which is for public usage and one via a read/write like call for configuration: * The events API has a "bridge" to usermode, the /dev/event devices. These are quite like /dev/graphic, but bidirectional. You can have any number of such devices (well - 255) attached to any kernel stack. This means you can attach additional stacks from usermode * The read/write API is automagically exported to /proc, so configuration is always /proc based. It is also tied to reading/writing a proc file, but can be called internally, too, to allow for a "secure" path between kernel modules. All commands on the RW API are human readable, though sometimes a bit number-loaded Theses Stacks are source-compatible with the corresponding kernel module, so they can be moved freely if they do not rely on say IRQs. E.g. leave only the keyboard driver in kernelspace, and the rest can go into userspace. Only problem is with a userspace stack you cannot have a "real" device which allows ioctl. The keymapping however _can_ be done in userspace. Evstack would broadcast an event with event type being "raw keyboard code" and event data being the code itself. The EvStack code has some special stacks (well nothing special about them really) which tie together some stacks to make up a console. One of the attached stacks that make up a console is a "scroller". This scroller is interchangeable and the default scroller accesses the normal KGI functions for updating FBs. However you can easily plug in another scroller which calls GGI_COMMAND interface thus allowing for graphical scroller easily. Scroller modes and hardware modes are distinct (e.g. virtual 80x25 mode on 100x37 hardware mode) and are detachable from each other, to facilitate the swapping of display drivers. You can bind any stack-combination you want _per_vt_. There is a VT-stack which holds all the necessary helpers attached to it. Configuration works like: echo attach stack-no >/the_holding stack. Thus you make up a bundle of stacks for each VT which describe all input and output facilities and all convertors, bridges, etc. Each head also has a kind of "template stack" from which it copies the default stack for newly created VTs. E.g. with a board that doesn't support textmodes but only graphics, consoles are automatically graphical. There will be some hardcoded templates for bootup and then a new one is made when the system comes up. It is configurable externally. EvStack will be a _totally_ optional feature in the kernel. The drivers have their own subdir and you can select EvStack at compile time or leave it out. We think we will easily go into the kernel. We don't break a thing, if you disable us. Even if you include it, XFree86 and other root-graphics programs will still work, but once a display driver gets loaded, they will not, as the stack supporting the fallback will be removed and replaced by ours. EvStack will need some changes, but we do not yet know what exactly. LibGGL/3D ========= Uwes patches to LibGGI allow us to do something like ggi_register_extension. This call will allow a library running on top of libggi which should be thought of as a simple library manager. He also has Mesa using LibGGI to display. LibGGL is a reimplementation of the OpenGL API, plus library context. It is an experiment to improve software rendering (better than current Mesa). We needn't implement the full OpenGL API to tell if it does better than Mesa, though. The actual libGGL.so will be a bunch of stub functions that will ensure thread safety, and do profiling if needed. This way we can simply do a 'real' OpenGL wrapper around (just like the mesa internal code). However, the low level code will be done the same way if the fragment processing is fast enough. [insert fragment definition] However, the calling interface there is not as it should be. I would like to collect all the fragment related stuff in a struct. Basically x,y, z screen coordinates, texture and fog parameters, and up to 32 pixel properties. The rasterizers will calculate the x,y, and z values and interplolate the texture coordinates, fog and attributes. One call per fragment. However, the DoFragment will just get a pointer to the struct mentioned and the rest is compiled into the DoFragment function. [23:56] So, everything is hardcoded, no pointers to be accessed or large structs to be changed. Hopefully this will give us the speed needed to compensate for the 'call-per-fragment'. HW accelerations comes within the calling scheme. For instance, you will have to give the triangle function three pointers to vertex information. And as pipelining is concerned, I think it pays off for the more complicated situations, like doing alpha blends, zbuffering, etc. Given the primitives are rendered this way, you can cut the rasterization at any level. /* It is possible to do HW interfacing just as LibGGI does via the ggiRegisterExtension call. YOu will be tolds which basic libs (like linear-24) the libGGI management core is loading and you can thus load and specific lib that speeds up rendering for the given configuration. The idea is to normally have a card-specific layer, if the card is any good at it. Thus e.g. vendor/Permedia/perm_mesa.so is loaded for Uwe's port, if this vendor driver was requested. However, some more info may be needed to setup the driver. */ [I don't understand all the 3D stuff; might need more explanation here.] Other Things for Degas ====================== Merge all display drivers and patches floating around. Possibly more demos. Change display drivers to work with new EvStack interface. Should not be much work; a few tweaks in a few places (the scroller stuff partially). [Steve Cheng, Sat Dec 20 1997] -- Steve Cheng elmert@ipoline.com