On Tue, 19 Mar 2002, Brian S. Julin wrote:
[...]
>
> KGI directories other than libkgi should be moved to an attic, IMO,
> Since they cannot drive the current KGI. libkgi is the playground.
>From what I've read in ggi-core/libggi/display/libkgi/ and
ggi-core/libggi/include/ggi/display/libkgi.h ; for the moment, libkgi
contains/uses libgalloc (the "rotor" things?). So (correct me if I'm wrong
please), libkgi (the in-GGI code) is prepared to use an advanced hw engine
via display lists (aka batchops the galloc way). However, libkgi does not
really incorporate any code to actually *use* the current KGI? (Except a
#if 0-ed go to kgiInit() in GGIopen.)
KGI is more or less frozen for the moment (not much activity on the
mailing list for 2-3 months). I'm as guilty as someone wrt this but I'd
like to see some improvements.
It seems to me that batchops-in-libggi + display-list-in-KGI will not be
production-ready soon (either because batchops is a new idea in GGI, or
because the mmap()-based display-lists execution system currently working
in KGI does not seem totally satisfying to those that know him).
Similarly, elementary drawing commands (ie: the "drawline" ioctl() and
co.) are not ready in KGI: Steffen wiped out the last kgi_command_t system
before going back on the design board, and nobody really knows what he
really invented then for KGI. [1]
However, mode-setting commands to obtain a fb access could be extracted
very fast from the KGI CVS tree (currently *every* test program
in the KGI tree incorporates a copy of these 6-7 functions that sums to
~100 lines of C code). These functions directly uses ioctl() commands that
the KGI-enabled linux kernel understands and that can be used to setup a
mode and obtain access to the primary mode resource: the framebuffer.
I know that Steffen Seeger (the primary KGI author) wants to
create/maintain an independent libkgi to offer a userspace abstraction of
the KGI functionality (and because it may be a key part of his graphic
world domination grand plan). But until it is ready, I *really* think that
we should copy these 6-7 functions from the KGI source tree into libggi
and rush towards framebuffer-based KGI applications. [2]
In fact, this is my question: with only a framebuffer provided by the hw
driver, will most of current GGI applications run decently? (BTW, my guess
is "yes of course!")
That could give a boost to those wanting to try some KGI driver
development *now*; because they could see some applications running.
(Going through up to mode-setting is 90% of driver development work IMO.
The rest is not so important - except maybe for the 3D engines that
correspond nearly to a driver-in-the-driver.) It may also give a boost
to those thinking to port some application to LibGGI (esp. games).
For the advanced features, ie: hw acceleration of drawing primitives (via
display lists), the Matrox hardware can serve as a testbed to validate
GAlloc operation wrt display lists. (Up to 3D if you want to.)
Rodolphe
[1] While reading my mail, the GGI people on this list not knowing well
KGI are probably starting to think that the situation is pretty
desesperate if KGI does not even know how to draw a hw-accelerated line...
But it is not: this is an *interface* problem. Demo/test programs that
can ignore this interface issue (because they do not need to bother about
API standardization if they target a specific system+hw combination for
testing) *are* written: I can demonstrate programs using hw-accelerated
display lists with 2D or even 3D primitives on Matrox boards...
So the core of the engine *is* running: it's just that we still wonder a
lot on how this engine should communicate with the outside world...
[2] It's been >5 years since I've last seen showaccel run full screen over
an home-made driver... I cannot wait anymore... it's too hard... my hands
are shaking...
