[IRC session summary: This summary highlights the important decisions reached on various aspects of GGI. I have included the basic rationale for the decision, if possible. I have quoted liberally, if the signal level makes it possible (if I have misquoted anyone, please correct me.) However, if more information is needed (e.g. why solution (B) was not adopted, etc.), please read the full log relevent to your topic. Especially I will not repeat the two licensing wars here :-)] CVS scheme ========== There are, of course, two CVS repositories: development and stable. Only a few people will access the stable repository, while all developers can use the devel repository. Both development and stable will have read access for all. Devel and stable are two different trees. Periodically, the stable maintainers will diff devel code back to stable and thoroughly check the code. This is to ensure that there are no incomplete/inconsistent/ uncoordinated changes to stable, and it will always work for non-GGI-developers. Development should go full speed at the devel tree as usual. New directory layout ==================== The KGI-specific "driver libraries" of LibGGI have been moved to the the kgi/ directory. This includes all the vendor-* libraries. The display-kgi target itself stays in LibGGI. Rationale: Easier separation between LibGGI and KGI, and to prevent the LibGGI tree to get too bloated. "They [KGI driver libraries] are taylored for specific KGi drivers. Though they are technically part of LibGGI, they have to be engineered to meet the KGI driver. Thus they should be close to it." "The patches directory will probably be renamed to something more generic and will hold all "OS-addendums" we need to make KGi drivers run on a particular OS." On the topic of includes and packaging: "... having a top-level include/ subdir, making a seperate package, as Stefan is suggesting, would be a good idea. this way the KGI target could remain part of libggi package, and the KGI backend libs can be moved to the kgi package" Makefile customization have been moved to a toplevel directory. The development trees will be a 'full' system, which includes almost everything. In the future, it should be possible to automatically "Split things to several packages that can be downloaded seperately [for non-developers]. The goes for Libs and such. [also: vendor libs]" New libGGI extension scheme =========================== For full API details, please read Andy's message to the GGI mailing list. Basically it allows per-visual extending and overriding of the underlying API. Some things that are currently in core LibGGI will be moved out to a smaller extension: * ggi*RayPos and friends -- CRT specifics * other "mode tweaking" * ggiSetSplitLine Rationale: Not all targets implement the above functionality nor do they make sense on some targets. Eases porting of main libGGI. Complex mode negotiation ======================== "The new extension scheme allows to connect into the communications channel established by the LibGGI display-* module. This means, that we can link into the communication LibGGI->X or LibGGI->KGI and thus even change very basic things like mode negotiation. This enables us to schedule the complex mode negotiation for later and make mode negotiation schems that fit the current application (3D, video, ...)" [LIBGGI Topics] 1) Multiple buffering ===================== Multi-buffered modes will be done by setting the "frames" member of the ggi_mode struct and passing that to ggiSetMode(). Two manipulte buffers, use: * SetDisplayedFrame() * SetDrawingFrame() Simple clipping on ggiFlush() ============================= To enhance targets having to emulate a DirectBuffer, by restricting flushes to small areas. Have "some kind of clipping list which is initialized to the full display, and reinitialized to that after a ggiFlush() .. and modified by a new call. This way, old applications will still update the full framebuffer, while applications aware of the new call can restrict changes.." Nested calls to ggiInit()/ggiExit() =================================== "Change returncodes, so you can detect it was the last "Exit" that actually cleaned things up." (These calls will nest, and are paired. ggiInit(), if already called, will just increase the counter, and decrement on ggiExit(). When it reaches zero ggiExit() will really deinit the library.) Switch-away/switch-back behavior ================================ Question: "What has to be done when a program is switched away (either the window (in X) becomes inactive, or the VT is switched), and on re-activation?" No protocol implementing any of this behaviour has been decided. Possible solutions: "A callback mechanism (Extensions already have it) that handles this." Or the program can specify behaviour to library. Current KGI implementation: "On switch-away (loss of input focus) a libGGI app gets SIGTSTP. On regain of focus, libGGI app gets SIGCONT. If the app has to redraw, gets SIGWINCH" (Iconification and focus change of windowed targets are other similar situations but no specific protocol has been decided.) Alpha values in ggi_color ========================= [There's no clear conclusion here in the log. I hope I get this right.] Alpha values should go into the ggi_color struct. Rationale: "otherwise another wrapper struct is necessary for anything that wants to use [alpha values]." ("However, basic libggi ignores it.") Some modes have spare bits. ggi_color is intended to be for "a few local variables"; i.e. not buffers or DirectBuffers of any type. Porting drivers to Degas ======================== There are a lot of differences: * Changes in the struct kgi_display * Changes in struct kgi_mode * New fields * all the timing info is now in kgi_mode.tm * textop function table * versioning "The rules for what you can attach to the structures has changed to be much more strict." "GGI Console (the new name for `EvStack') uses the driver's textop virtual function table to provide a lot of the functionality for drawing on the framebuffer. Eventually, a set of in-kernel `This is how you draw text on a linear-X framebuffer' textop structures will be in place, a la textop_linear_text16." EvStack interacts with drivers through a scroller, which replaces the old text16 stuff. Scrollers provide a backbuffer (UTF 16 currently), and is used by the terminal emulation to render on the screen, in both text and graphics modes without difference to the driver. To clarify, "fbcon and KGI are both display targets of the GGI console (EvStack)." (KGI/EvStack now in devel tree.) KGI Display Driver Guide in progress. Also "see the current documention in degas/kgi/doc for some hints. It'll be fully fleshed out soon." display- prefix on target names =============================== e.g. "display-memory" vs. "memory" "Have both by using /etc/ggi/libggi.conf set up accordingly. Official version as used in overriding libs and such is display-*". [... I wish all libggi decisions were as easy as this ... You mortals have been spared from the evils of reliving the horrors of cutting the IRC log :] Layout of memory visuals ======================== [A bit vague here.] Use LibGGI driver libraries (linear-*, etc.) on the memory visual to mimic the layout of the framebuffer. Copying between the memory visual and DirectBuffer will be faster -- no CrossBlits. Graphtype values ================ "The graphtypes are "GT_XXX + depth" e.g. GT_RGB + 16. The resulting mode still could be r5g5b5, or r5g6b5, or r6g6b6, with or without byte swapping, or ..." [No clear decision here on actual implementation in driver libraries. Probably the first one:] Separate linear-* and color-fixed-r5g6b5, etc, like current generic-ramdac. At mode setup load these libraries. -= OR =- "using DB names for the libs: linear-r5g6b5 etc... [which] would load a generic linear-16 (for pixel-stuffing drawing), and contain code for ggiMapColor() etc." ggiGet/Put* buffer opaqueness ============================= Currently: "ggiGet/PutHLine and friends have no documented buffer layout. The only guarantee is that the size of the buffer is width * height * sizeof(ggi_pixel). This is bad because one can't prepare a buffer 'offline' and then blit onto the screen." Extend DirectBuffer: "Having the getbuffer call accept a new exported pointer as the "get first" parameter (which is yet defined to be NULL) and thus allow it to query any buffer format, not only the screen one." That is, use ggi_common_plb_setup values to specify format. Could be named "like DB_FRAMEBUFFER, DB_GETPUTBUFFER, DB_ZBUFFER". ggi_info_db to be deprecated in favor of DirectBuffer. GGI licensing ============= [I can only say is that there's no decision reached whatsoever (except #includes/samples). Frankly, I hate going through all this licensing debate. It's a religious issue that is repeated everywhere in the Free Software Community. I see the debate is still raging on in the mailing list. I don't mean that licensing is unimportant; in fact, please fill out Andy's survey on this issue to get it sorted out quickly. All I will try to do here is summarize some main points.] (1) "#includes and programming samples should be as free as possible." --> BSD licensing with the "give CREDITS" removed [why don't you just call it X-style license? It's more clear (no advertising clause)... and allows you to "sublicense" -- meaning code can be incorporated into GPL code? *duck*] (2) LibGGI as LGPL No requirements to ship source with commercial apps Of course, get back contributions to code. Using static linking, it is possible to fix library because "object code" is shipped. --> decided at first, but seems to be some opposition now... "LGPL is still restrictive" to BSD Loss of freedom (in some aspects, at least). (3) KGI "the Linux-specific kernel portions ought to be GPL" i.e. "degas/os/* - as appropriate for target os" GPL must link only to GPL; Linux is GPL and requires GPL. Otherwise KGI must be modules. Of course BSD requires BSD license. "We NEED to put them under some license that is compatible with _all_ OSes we want them to run on ..." Seems impossible. See above. Public domain is out of the question. No control of code whatsoever. Dual license: Some contributors might not agree to release code under both licenses (BSD, GPL). There could be multiple source trees. i.e. a split, more duplication. "We should allow all driver authors to use whatever license they want. However I think we should propose a very free license as the default." [Still screwed.] "Now if this linking poses a licensing problem, then lawyers are weird. Conclusion : Lawyers are weird ..." :) "I think we should postpone this discussion, as it doesn't seem to lead to anything... we should check with some people with experience in that field (bruce ? eric ? Richard ? ...)" [just for clarification: Bruce Perens, Eric S. Raymond, Richard Stallman] [Whew... Now that CVS is finally open and hopefully most issues sorted out, let's start coding!] // Steve e-mail: steve@ggi-project.org www: