lkml.org 
[lkml]   [2006]   [May]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Add a "enable" sysfs attribute to the pci devices to allow userspace (Xorg) to enable devices without doing foul direct access
    From
    Date

    > By allowing tools to read the rom from the pci device itself, instead of
    > whichever device's rom happens to be at 0xC0000. libx86emul allows you
    > to define routines that it uses for memory access, so you can copy the
    > ROM out to normal memory, and map that memory to the appropriate address
    > that way. X and vbetool both already have to do this, but without
    > copying the firmware image, to do DDC probing on x86_64.
    >
    > > I agree with Arjan that the attribute could be useful for some special
    > > tools, but using it in X is likely to be utterly wrong.
    >
    > I'm actually talking about vbetool here, though X could use these
    > methods. Indeed, libx86emul comes from X itself.

    There are reasons why you may have to read the image at c0000... There's
    a bunch of laptops where it's in fact the only way to get to the video
    BIOS as it doesn't have a ROM attached to the video chip (it's burried
    in the main BIOS which thankfully copied it to c0000 when running it).
    In some cases, the BISO ROM self-modifies it's c0000 and it's that
    modified copy that the X (or fbdev) driver should get. Remeber that
    drivers needs access to the ROM for more than just POSTing the chip...

    In addition, we need to centralize VGA routing mecanism in the kernel
    for other reasons. For example, because it might imply disabling MMIO or
    IO access to other cards (currently, we have to disable _all_ other
    cards on the same bus segment that claim to be VGA since we have no way
    to know which ones might be able to simply be configured not to decode
    legacy VGA accesses, though an appropriate arbiter ABI would allow to
    handle that too). Thus am fbdev or X server currently running on another
    card would explode in flames while something like vbetool is re-routing
    VGA access to a card for POST'ing or other things vbetool can do.

    It's a shitty problem, it's complicated, but there is no easy way out
    thanks to PC manufacturers and Intel keeping absolutely disgusting VGA
    "legacy" crap part of the PCI standard for so long.

    Note that I posted various prototypes of what a VGA abiter could look
    like a while ago. I have no time to resume work on that and my
    prototypes weren't perfect, but that's something one interested party
    could probably use as a starting point to a more complete solution.

    Ben.

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

    \
     
     \ /
      Last update: 2006-05-14 02:32    [W:0.023 / U:30.220 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site