On Wed, 29 Sep 1999, Andreas Beck wrote:
> > > 1) Is the ioctl ACCEL_GETSUGGEST still in use ?
>
> We should reactivate it. It's a drawback not to have it.
Well, we never really needed it until now.
> > AFAIK it is not is use anywhere, but as soon as we start doing
> > anything complex with KGI driver (i.e. now), the suggest-strings feature will
> > be very useful/necessary. I am considering implementing this feature via
> > 'cat /proc/gfx[n]/suggest' or something similar.
>
> I don't recommend that. I'd like to have that call in the primary command
> path, which is just about all a KGI-using module should need to know for
> startup purposes. This will help tremendously when porting LibGGI to other
> architectures, as only a single API call needs to be overloaded.
Good point. I had thought to treat the suggest-string as a static
resource which needed to be "mapped" in some way as the mmio regions are, but
I guess that is not really necessary.
> > not quite that easy. I just looked at LibGGI2D and it does not have a
> > display/ subsystem at all yet, and no default/kgi subsystem either. Both
> > will have to be added before LibGGI2D can cleanly overload the accelerations
> > of LibGGI's fbdev and genkgi targets. Still not all that hard, though.
>
> Yep. Is LibGGI2D actively maintained right now ? Thomas ? Still there ?
> If not, I'd suggest to have it rewritten by those adding actual 2D accel
> support to their drivers. Would also resolve the license issue.
These issues are why I suggested to start with 3D accels. There is
more immediate need for 3D support, and the GGIMesa framework is more
complete. If GGIMesa accels are made to work well first, we will have a LOT
less work to do for LibGGI2D.
> > Now you have your KGI functionality in LibGGI2D. But, it is a
> > generic functionality - all KGI drivers must be handled the same way (as in
> > LibGGI right now), because you do not have any genkgi sub-libraries to handle
> > the features of the individual KGI drivers or driver families (e.g. S3's
> > STREAMS). To fix this, we need a genkgi.conf file for LibGGI2D, some sublib
>
> I think that is overdoing it a little, isn't it ? I'd just stick that into
> the main libs config file.
I thought we were going to keep the .conf files small and separated?
If we stick everything in the main .conf file, we will have a dynamic
registry instead of static .conf files, which we currently have no way of
intelligently managing. This is not necessarily a bad thing, in fact it
might be a good thing to do away with all the individual .conf files and move
to a central system registry scheme. But we do not have the tools to manage
such a database. Or do I misunderstand?
> > > 3) Where in the directorystructure must I implement my S3 ViRGE libggi2d &
> > > libggi3d libs ? I couldn't find any suitable location in my CVS snapshot.
>
> > libggi2d/default/kgi/mode.c
> > libggi2d/default/kgi/visual.c
> > libggi2d/default/kgi/genkgi.conf.in
> > libggi2d/default/kgi/s3/gens3.c
> > libggi2d/default/kgi/s3/streams/genstreams.c
> > libggi2d/default/kgi/s3/streams/trio_streams.c
> > libggi2d/default/kgi/s3/streams/virge_streams.c
> > libggi2d/default/kgi/s3/streams/savage4_streams.c
>
> Actually the "vendor" branch was intended for those drivers, but ...
...But the vendor branch does not yet exist, and for it to exist we must
figure out how to manage a dynamic registry. Do we know how to do this yet?
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
