[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: [email protected]
www: <http://shell.ipoline.com/~elmert/>

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.