VGA arbitration: API proposal

[Egbert Eich]

Alan Cox writes:
 > On Sad, 2005-03-05 at 16:37, Jon Smirl wrote:
 > > What about legacy code that doesn't contain vga_get/vga_put. brackets?
 > > You can't just do this on VT switch in the simultaneous user case.
 > 
 > I don't think that bit is actually the problem.
 > 
 > Right now the console is kernel side so is easy and can do vga_get/put
 > itself happily enough. The fun starts with the user space applications.
 > Now all of these tell the kernel they are using the graphics directly
 > via a vt ioctl that currently means "don't print panic messages, do
 > funky vt switch". That ioctl can be made to mean "older user space
 > application hogging the vga".

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

 > 
 > The bigger question is what the API for userspace looks like for new
 > "well behaved" applications that touch on VGA because the moment a user
 > 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?

Cheers,
	Egbert.