Hello,
I can remember a time when this projet attracted too much attention. (I'm
sure several people on this list also remember that disastrous email burst
originating from the linux-kernel folks in mid-1998.) Since then, I've
never regretted the fact that GGI hides back in shadows and that
ggi-develop remains a peaceful place. It seems to me that silent reading
and careful writing from this list subscribers is the best we can hope
from them (apart from a friendly atmosphere, and a macarena dancing
minions master).
1) Concerning the goals of the project itself, I agree with the fact that
libggi and libgii, the central pieces of LibGGI, are now pretty mature and
useful. So they surely deserve some "stable distribution" action.
Afterwards, users feedback and requests may lead their development towards
useful areas that we have not yet thought of.
Furthermore, once this is done, maybe Andreas and Marcus, our best experts
might extend some other part of project they are interested in.
(Aren't you a little fed up with your babies now, boys ? ;-)
2) I really think we should now put more effort in the direction of KGI
and direct support of advanced hardware features. (The new KGI I mean,
not KGIcon or any fbdev related compatibility thing.)
I don't know if this feeling is shared by other people on the list, but
I'd really like to have both parts of the project in sync again, advancing
at the same pace.
Maybe it was too ambitious in the original design to try to support AND
_emulate_ (when they are not available) all the drawing functions of
graphic boards. But it would be extremely useful to support those that
they now provide in hardware. (And, well, in 3 years, graphics chipsets
did an impressive technological leap: we need less and less emulation --
luckily, we did not implement much ;-).
2.1) This probably means that we should further advance in the direction
of GGI2D and GGI3D over a KGI-like API! (And do not bother too much about
emulation unless someone explicitly requests it. Several times.)
Jon did several thing to GGI3D in the last year - but I have to admit that
I did not understand everything. :-) Some re-explanation and source tree
"guided tour" would be nice if someone has time to explain.
GGI2D should be easier to do now that LibXMI can take care of the 2D
software implementation of drawing functions. No?
2.2) This probably also means that we should try to focuss again on driver
development for KGI. Jon once proposed to standardize on a common hardware
platform for achieving such aim: personnally, I agree. You all know the
constraints: not too expensive, not too old, widely available, available
documentation, and as few hardware bugs as possible. (Deliberately, I do
not propose any "preferred" board, just to show you that I _really_ adhere
to the idea and do not want to point at one chipset in particular.)
This would allow us: to focuss on one "sample" driver, to try to support
all the hw features of the target chipset, to demonstrate and evaluate the
full power of LibGGI wrt to hardware acceleration access -- and to attract
a lot of attention if we want! (Do you know something better than a 3D
acceleration "benchmark" to attrack a lot of web surfers on your site ?
;-)
2.3) Forget about linux integration. Building a patched kernel has never
been a problem, even for beginners, while trying to propose KGI for the
mainstream kernal has _always_ been problematic. Anyway, KGI is something
that Unix as a whole has never seen yet (except maybe on some SGI
variants), so, maybe it's better as a separate patch for the moment... In
fact, IMHO a port to FreeBSD (or OpenBSD given the potential security
improvement) would be much more interesting from a technical point of view
than continuously focussing on Linux-centric issues.
2.4) Try to find new ways to extend the GGI scope: Berlin-on-GGI is surely
one way, OpenAmulet-on-GGI was also an idea (of mine maybe too late),
CrystalSpace on GGI was one also at some time in the past and I think we
should revive that one, XMI-for-GGI was one (successfully brought to life
by Jon), KGI-for-UDI was also one (whatabout ISO-2001-KGI? sexy isn't it ?
:-) ). What a variety ! At least, we should do some paper work on these
subjects (at least for history).
It seems to me that this project always had a very "research-oriented"
profile. So, why not go even further in this direction? For example, I'd
really like to propose some sort of hardware description language (and the
associated "translator") to produce the headers of a KGI driver (and all
the xxx_{in,out}{8,16,32}() functions that are so boring to write). What
about inventing a new language for writing graphic cards driver ? It may
even speed up our driver development schedule (after the 2-3 years
language development overhead of course :-).
3) It's a little early to write a full book on the GGI project. But at
least, I think two chapters of the hypothetical handbook should be
written: "Chap. 2: LibGII", and "Chap. 3: LibGGI". I mean it.
Well, as usual, a french mediterranean guy always speaks too much. Please
tell me if something I said attracted your attention.
Amicalement,
Rodolphe
PS: No, finally, I changed my mind. Tell me if something did NOT interest
you. (Just in case nobody answers... ;-)))
