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

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