From: becka@rz.uni-duesseldorf.de
  To  : ggi-develop@eskimo.com
  Date: Fri, 13 Aug 1999 11:11:13 +0200 (MET DST)

Re: GGI and XFree86 and stuff

Hi !

> > Before we get overly enthusiastic about PingPong and stuff:
> > The locking problem needs to be solved. If we go for an asynchronous

> I'm assuming this is for cards that can't have the framebuffer and accel
> accessed at the same. 

No. This is for each and every card. Say you want to erase the screen and 
then draw a diagonal line on it. Assume further, that boxes are accelerated,
but lines are not.

Now if you issue the fillscreen command, and it does not get executed 
immediately, but only at the next buffer flush, you will draw the line 
first, and lateron, when the buffer is full and gets flushed, you will
fill the screen. This is obviously wrong, as the net effect is the line 
not being visible.

Therefore, accel queues need to be flushed before fb access takes place.

This requires, that every fb access acquires a lock, that will block until the
queues are flushed and the accel is idle.

For cards that will lock up on concurrent access, we will have to enforce 
the lock by using map/unmap. For others, the lock can be advisory.
If you don't stick to the rules, you get crap output.

> fbcon-cfb* functions. Now the problem is if /dev/fb is mmapped. Kernel
> side I can keep track of when the accel engine is busy/idle but I don't
> know how to tell if someone is writing to the framebuffer itself. 

You need to mmap/unmap. 

For the advisory lock I talk about above, you simply use a variable in the
kernel-mapped GC. The kernel will set/reset it if accel is busy, and the
userlevel locking code will check it, if a lock-acquire is performed _and_
modify it to change the kernel behaviour to always use synchronous accel.

That is to say: 

If the mmap lock is free, the kernel can delay accel operations or to be 
precise it can queue them up, without waiting for completion.

If the lock gets engaged, it will wait for the accel lock to become free
and then the mmap lock is set.

>From then on, the kernel will execute accel commands atomically WRT to the
application.

When the lock is freed again, we go back to normal.


CU, ANdy

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