From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Wed, 2 Jun 1999 22:33:47 +0200

Re: GGIMesa updates/questions

> > * I cannot seem to get kgi-savage4.so to be used by GGIMesa.  ggimesa.conf
> > maps 'display-fbdev-mesa' to the .so correctly (well it is a hack but...), so
> > kgi-savage4.so does get loaded and its ggi_dlinit() function is called
> > properly as well.  However, in spite of the fact that display-fbdev-mesa is
> > the last line in ggimesa.conf, ggiGetAPI() apparently insists on loading it
> > _first_, before generic-stubs-mesa and friends.  The end result is that the
> > GGIMesa private function pointers, which were initially set correctly by
> > kgi-savage4.so, get reset to the stub routines immediately afterward.  No
> > other extension implements both default/ and display/ subsystems, so I
> > have no example to look at in this situation.

> After a quick look at things it's obvious that we need to make the
> API lists more flexible. For example it is desirable to have extensions
> being able to add APIs which LibGGI itself does not know or need to know
> about.

??? The _driver_ should know about the APIs. That is, the _driver_ should
export a set of string describing which APIs the card exports. I always
wondered, why the heck that code was disabled in the KGI directories:

/* We don't need the suggest stuff for kgicon */
#undef NEED_SUGGEST_FEAT

You are right, that LibGGI should not need to know. Thus for fbdev,KGI and
friend TRTTD is IMHO to reactivate the kgi call for getAPI and have the
driver export a list of APIs.

It's simply that the driver exports something like :

(generic-stubs)    - implicit map from LibGGI not exported as it's no real API.
generic-linear-8   - _driver_ exports a LFB for linear-8
generic-kgicommand - driver can take KGI-commands. That is, the interfacing
 code (the display-* lib) should have filled in the kgicommand pointer and
 the generic-kgi lib should be loaded which will send commands through that
 interface. Note, that the suidkgi target will use a direct call in the
 kgicommand pointer, while the fbdev target will use ioctl().
vendor-s3          - this is an S3 board. Load an eventual common accel dirver.
vendor-s3-savage3d - it's a savage-3D

IMHO mayn of the drivers have been broken in that respect ever since, so it
might be a good time to fix it.

Shall I set up a "template" for a (IMO) "correct" implementation of that ?
(I admit, I didn't do it for the PM driver as well, as it worked without).

> I propose we make the API list a property of the visual (not the target
> as now, but the list is still initialized by the target at setmode time)
> and add a new internal function:
> _ggiAddAPI(ggi_visual_t vis, const char *api):

Why should one add an API later ? Because the extension might be needed to
detect it ? IMHO for the "good" systems, there should be an exported APIlist
by the driver.

> So the complete API list after the fbdev target is loaded on a kgicon
> driver would look like:
> display-fbdev
> generic-stubs
> generic-color
> generic-linear-*
> tgt-fbdev
> tgt-fbdev-kgicon-generic

IMHO the fbdev target should query the driver. That's how it was designed,
and that's foolprof IMHO.

> and when GGIMesa is attached display-fbdev-mesa would detect the
> presence of a Savage3D and add tgt-fbdev-kgicon-s3-savage3d to
> the API list.
> 
> Comments? Andy?

I don't think that's good. The suggest-strings feature was designed to do
away with that "and then we try to detect" stuff, which is IMHO very
risky business. The card should export what APIs can be used to access
it from the very beginning.

If the card exports MMIO areas, it is IMHO supposed to tell their format
in the list of suggest-strings.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =