VGA Arbiter

[Jesse Barnes]

On Friday, October 26, 2007 12:17 pm Paulo Ricardo Zanoni wrote:
> The problem is that we're still trying to understand everything =)
> The code is a little complicated and we've never played with PCI
> stuff. So we want to hear your opinions if we're going on the right
> way.

I can't see the code now, but I'm pretty sure you'll need a platform 
hook so that different architectures (possibly with weird host<->pci 
bridges) can route VGA correctly.  And of course for generic PCI 
bridges the standard VGA routing bits can be used.  For two devices on 
the same bus, I guess you'll need specific device drivers to 
enable/disable VGA code (not sure about this part)?

> To use the /dev interface you just write strings on the device and
> the kernel interprets it and does what it has to do. The interface is
> very simple and is explained at vgaarb.c:520 (kernel module code). It
> was originally written as part of the kernel, but we made it a module
> (to make easier to compile and test). The problem is that string
> comparing inside the kernel does not have too much performance.

Having the device driver take an ioctl that has a PCI ID in it might be 
a better interface (assuming PCI is all we want to support).

Are there also internal kernel interfaces for things like vgacon or 
driver save/restore routines to use?

> The xserver code is actually a modification in the RAC code. We
> wrapped the video driver calls with with "get_lock" and "put_lock".
> This is really not what should be done, it is just the easier way to
> test if things work. Currently, it is not working and we're studying
> X's code to see what we did wrong (maybe the problem is in the Kernel
> module).

Can the code just be hidden away in vgahw?  Or are there lots of drivers 
that bang on the VGA regs directly too?

> We want to know what you guys think about it. Are we on the right
> way? Anyone willing to help?

I can't get to the repos now, but I'm glad someone is doing this work!  
It sounds like the right direction at least.

Thanks,
Jesse