VGA Arbiter

Tiago Vignatti vignatti at c3sl.ufpr.br
Fri Oct 26 18:48:06 PDT 2007


Hi Jesse, how are you?! Thanks to answer this quickly. It's very 
valuable to us.

Jesse Barnes escreveu:
> 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)?

humm, what's the best way to see how is the PCI architecture of my 
machines? I just typed `ls /sys/bus/pci/devices/0000\:0*` in four 
machines here and all appeared a lot of device in the same bus but one 
or two in another one (and the domain, was always the same as you can 
see in the ls). So, this mean that I can assume the generic PCI routing 
could be in this form?


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

yeah, this could be easily implemented. We're using the char device 
cause BenH initially started in that manner.


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

don't know. Paulo? :)

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

As Paulo said, initially we just used the same code of RAC to wrap all 
that functions which calls vga. But we don't know for sure if that is 
sufficiently. We also traced the code and saw that others functions -- 
which is not wrapped by RAC -- like xf86EnableAccess() and 
xf86ActiveResources() also deal with vga things.


Thanks

-- 
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br



More information about the xorg mailing list