From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 3 Jun 1999 13:18:02 +0200

Re: GGIMesa updates/questions

> > (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, 

Yes. I'd like to add such a capability anyway. As of now, this is the "best
effort" to describe the exported framebuffer.

IMHO we should as well be able to export multiple framebuffers, as some
cards can export Big/Little endian and such.

> and for paletted modes the entrire initial palette. 

That is handled by the "generic-ramdac" API which I didn't include in the
example.

> Encoding all that into a string and have LibGGI
> parse it would be really weird IMHO.

Yes. The idea is that you know the generic layout, which joins all
"compatible" libs. linear-15 is IMHO nonsense. The difference to linear-16
is the encoding of the colors which should be queryable in another fashion.

> > Why should one add an API later ?

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

Yes - I see. You mean a card that is 100% compatible, but has some extra
regs in the already exported space ...

O.K. - if they can be queried in a dafe way, that would be doable.
Though I'd still recommend to patch the driver to avoid collecting
a big bunch of specific tests in the userspace libs.

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

Yes. See my proposal for the AddAPI you suggested.

Quick addition on that:

I think the struct *API should have a *private pointer which can be used to
store some extra data (like say the DB layout). It should be assumed to be
malloced memory which is free()ed when the API is deleted.

CU, Andy

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