VGA arbitration: API proposal

[Egbert Eich]

Alan Cox writes:
 > 
 > At the point you are displaying an oops the machine is already in a
 > pretty bad way and if the oops hangs the box then it's no worse than the
 > oops being lost and the box hanging as occurs now under X.

Right.
 > 
 > Time isn't always enough for the wait - on some chips you also need to
 > stuff bytes down the data fifo in case a blit from CPU is in progress.
 > That is something that can be improved over time and I'm sure the X
 > folks have a lot of expertise here.

When no data is shuffed down the fifo chances may be better that you
can access the framebuffer again.
The main problem is that a fifo may not be empty and things queued in
the fifo are still processed while someone else would like to access
the framebuffer.

 > 
 > >  > app can lock vga we are in deadlock paradise. We may in fact need a
 > >  > kernel API on the vga device to "issue vga sequence to device" which
 > >  > does the locking entirely in kernel.
 > >  > 
 > > 
 > > Hm, interesting idea. Could this be implemented in a driver transparent
 > > way? Meaning just change the PIO functions and handle thing transparently
 > > in a library and/or the kernel. Some 'cache' for register accesses?
 > 
 > Not really because the kernel needs to know which VGA device you are
 > talking with. There would also be a bigger performance hit to do that
 > than to take an
 > ioctl for it. 

Right. But the 'context' could be passed to the function as an additional
argument. I was referring more to the overhead that would be required 
to flush out the data.

Egbert.