From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Tue, 17 Aug 1999 00:10:18 +0200

Re: Ping-pong buffers on KGIcon are here!

> > either accels *xor* writing directly to the framebuffer, but how
> > about an application that (accidentially) mixes the two rather closely?

> That would qualify as a broken application.

No. The application does not know, what is acceled and what not.

> Yes, but the fault only happens when the application tries to
> access the directbuffer.  If it's doing it through a LibGGI 
> primitive like it should, the sublib is free to check the 
> accel_queue_empty GC flag and either sleep or ioctl a flush, 
> rather than faulting, and in fact the app code can do this as well.

The app code _must_ do this. On broken HW we must unmap/remap, as we can
lock the machine otherwise, so there is no choice.
If the card is "less broken", we can keep to advisory locking. See my mail
on that.

> GGI already can flush the accel queue and check for accel busy
> with the current API (as soon as Marcus's system is all the way 
> implemented in the new PP code.)  I don't see what change would be 
> necessary -- ??

API-wise none. We should check our internals and demos, though. Few lock
down the DBs I suppose.

CU, Andy

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