> > 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
2. This should be entered to the visual ops like this:
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.
= Andreas Beck | Email : <[EMAIL PROTECTED]> =