Re: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access

["Jon Smirl" <jonsmirl@gmail.com>]

On 5/4/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote:
> Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
>
> > There's already a "rom" file in sysfs.  Could vbetool and friends
> > use that?
>
> Not if you have multiple graphics cards.

Not true, the rom attribute maps the ROM into PCI space where ever the
kernel tells it to and reads it from there. It is the PCI VGA
emulation feature that forces the ROM to appear at C000:0. You can
have the ROM mapped and VGA emulation turned off.

This brings up another major point. X changes the PCI VGA emulation
routing from user space, another thing that it should not be doing. I
have posted patches before providing a sysfs VGA attribute on class
VGA devices. By setting the attribute to 1 you can control the active
VGA emulation device.

This is yet another way that user space can mess up the kernel. If VGA
routing is changes under fbdev (my attribute notifies fbdev, the fbdev
code for processing the notification did get checked in) then the
console will screw up. The usual screw up is that the console goes
blank because hardware fonts are not setup correctly on the new
console.

I also remember posting a patch for initializing all class VGA devices
at boot. This is a complication process since running the ROM will
leave that card as the active VGA device.  The initialization code
made sure to set the console back to the original VGA card after the
secondary one was initialized.  The initialization process needs to
run a user space app which provides real mode access or an x86
emulator. BenH has the x86 emulator code (people sticking PC hardware
into PowerPCs need the emulator). This code for running the ROM should
go into the kernel tree and work with klibc.

I would really like to see a well designed, comprehensive plan for
handling these issues instead of just providing convenience APIs (that
may be hard to get rid of) for the old X code. I'm willing to help if
people really are serious about fixing the problems.

I wrote down a lot of my thoughts on this area in the State of Linux
Graphics article last summer. There is a large section about kernel
issues.
http://people.freedesktop.org/~jonsmirl/graphics.html

>
> > How do vbetool and X coordinate their usage of "enable"?
>
> vbetool won't run at anything other than a text console, and X won't
> mess with the graphics card if it's not on the current VT. You can mess
> this up if you try hard enough (multihead, for instance) but by and
> large it's a situation that you can avoid.
>
> > What if we throw an in-kernel VGA driver into the mix?  But I guess
> > Jon has asked all these questions before; I just didn't get warm
> > fuzzies that there were safe, maintainable answers.
>
> This probably isn't the right long-term answer, but the right long-term
> answer is going to be a very long time away. It's an improvement over
> what we have now. I certainly don't intend to leave vbetool relying on
> it - of course, the "right" answer is for graphics drivers to know how
> to program cards from scratch so we can get rid of vbetool altogether,
> but I'll probably be more concerned about getting my flying car to meet
> new emission standards than I will be by graphics cards at that stage.
>
> --
> Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


--
Jon Smirl
jonsmirl@gmail.com