VGA arbitration: API proposal

[Egbert Eich]

Jesse Barnes writes:
 > On Friday, March 4, 2005 3:44 pm, Benjamin Herrenschmidt wrote:
 > > Egbert, Jon, any comment ?
 > >
 > > It could be implemented as a userland library for "default" OSes, that
 > > library using kernel facilities (to be written) on OSes that provide
 > > them (linux).
 > >
 > > As far as Linux is concerned, the toggling of VGA access with an
 > > in-kernel semaphore to be shared between userland toggle (via sysfs) and
 > > internal drivers (vgacon) has to be done, along with some indication (in
 > > sysfs too) of the decoding mode of the card as set by the driver (could
 > > be set by the kernel driver or by X, I suppose if they have different
 > > settings, they can switch it at VT switch time).
 > 
 > Seems to make sense to me--you really do have to introduce the concept of a 
 > VGA owner for cases where multiple VGA cards share the same bus or legacy 
 > I/O/mem decode segment.  In that sense, it complements the existing 
 > legacy_io/mem API presented by sysfs.
 > 
 > Might be nice if the  vga_set_legacy_decoding routine also returned the 
 > addresses of legacy I/O and memory space for that card.
 > 
 > This API is needed to properly POST multiple VGA cards per-bus, but it would 
 > be *really* nice if we could avoid using VGA at all after POSTing has been 
 > done (i.e. use the fb drivers instead of vgacon, don't use VGA ports from X 
 > space, etc.).  Of course that assumes that the full functionality of every 
 > display devices that we care about is a proper superset of the functionality 
 > they provide as VGA services, otherwise we'd be giving something up by 
 > dropping VGA based services.
 > 

Unfortunately we can't. There is too much hardware that cannot be
programmed entirely without using VGA resources - at least at some
point. Sometimes it would be theoretically possible but due to
HW bugs it is not. 
On modern HW this may not be such a huge issue any more but there
is still enough old stuff around.

Egbert.