VGA Arbiter
Jesse Barnes
jbarnes at virtuousgeek.org
Fri Oct 26 14:56:29 PDT 2007
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
More information about the xorg
mailing list