VGA arbitration: API proposal

[Alan Cox]

On Llu, 2005-03-07 at 08:46, Egbert Eich wrote:
> The kernel could print panic messages in almost all cases where there
> is a linear fb available if the kernel has informations about the location
> of the framebuffer start address and parameters like pixel format,
> fb stride, width and height of the display.

That's something Jon talked about some time before.

> Memory access would have to be enabled - but this should not be an 
> issue for oopses and panic messages as at least one card should have
> these resources enabled and to the user it shouldn't matter which one 
> it is as long as he can see messages on one of the heads.
> Only 2D accel creats a slight problem here:
> Some chips don't like when someone writes to the fb while the 2D engine
> is active. 
> This could be 'worked around' by waiting a sufficient amount of time
> until accessing the fb.

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.

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.

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

Alan