> > and KGI 0.0.9, so that you can use KGI drivers on both stock and patched
> > Linux kernels.
> You do mean KGI 0.9, right?

Oooops - right.

By the way: I found a little bit of time yesterday to hack on GGI again. I
added flat triangle drawing to the Permedia KGI driver. 

As I (for testing purposes) tried to use the kgi-send-command feature of
LibGGI I found that it failed. I have now enabled it for the fbdev target
and I will try to explain how it was all intended to work:

1. When a target finds, that it is ultimately (after going through whatever 
stuff is in between) running on a KGI-type target, it should try to
establish a KGI command channel to that target (if that goes through ioctl,
pingpong or DMA does not matter) and wrap it up in a way that resembles the
ggifunc_kgicommand prototype.

2. This should be entered to the visual ops like this:
        vis->opdisplay->kgicommand= GGI_fbdev_kgicommand;

Now we have a transparent channel that will carry all KGI commands, but we
have abstracted it from the transport which currently can be ioctl and
direct calling for the suidkgi target.

3. When a KGI-enabled target is found, the display lib will know (see 1) and
should modify its list of APIs to contain a genkgi interface at the top of
its list. When we have reenabled the getAPI KGI call, we should get the
API-list from the KGI driver.

4. The genkgi rendering lib that is loaded shoudl route its traffic through
the kgicommand entry. This allows it to run transparently over an abitrary

I will make changes to LibGGI to that effect. It should not break anything.
If I do break something, please notify me.

When that change is through, implementing alternate communications channels
should be much simpler.

CU, Andy

= Andreas Beck                    |  Email :  <[EMAIL PROTECTED]> =

Reply via email to