From: Marcus Sundberg <mackan@stacken.kth.se>
  To  : ggi-develop@eskimo.com
  Date: Wed, 02 Jun 1999 21:39:42 +0000

Re: GGIMesa updates/questions

Andreas Beck wrote:
> ??? 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.

Yes, I can agree with that, but then it needs to be fixed a bit.

> It's simply that the driver exports something like :
> 
> (generic-stubs)    - implicit map from LibGGI not exported as it's no real API.

Yes, this is clearly not an exported API.

> generic-linear-8   - _driver_ exports a LFB for linear-8

Not an exported API either. An exported _API_ would consist of basicly
all the information in the DirectBuffer structure, and for paletted
modes
the entrire initial palette. Encoding all that into a string and have
LibGGI
parse it would be really weird IMHO.

> 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

Yep, this is ok except that the the latter two would begin with
vendor-creative- for Jon's drivers.

> > 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.

Because I don't think you can convince the fbdev people to start
using suggest-strings for normal fbdev drivers. ;-)
Also, we really need that flexibility for the case where a driver
just exports the registers and a newer, but backward compatible card
is released. If for example the new card just has a new 3D engine added
it would be stupid to have to distribute new KGI drivers (perhapps
binary)
when all that's needed is a new sublib for LibGGI3D.

> > 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.

Agreed for the drivers we have control over, but we still need the
functionality for other drivers and flexibility.

//Marcus
-- 
-------------------------------+------------------------------------
        Marcus Sundberg        | http://www.stacken.kth.se/~mackan/
 Royal Institute of Technology |       Phone: +46 707 295404
       Stockholm, Sweden       |   E-Mail: mackan@stacken.kth.se