Proper way to enable port access tracing with current xserver

Alex Deucher alexdeucher at
Fri Jan 16 12:58:16 PST 2009

On Fri, Jan 16, 2009 at 3:21 PM, Alex Villací­s Lasso
<a_villacis at> wrote:
> Alex Deucher escribió:
>>>  From what I glean from the traces, it seems that using VESA to start up
>>> the primary Savage chipset works correctly. However, when trying to
>>> initialize the Oak chipset as secondary (just that one, without
>>> reference to the primary Savage chipset), it ends up in a loop of
>>> in(3da) = ff and hangs. Interestingly, I saw no hint that the Savage
>>> chipset was ever moved out of the legacy  VGA mapping in order to
>>> initialize the Oak chipset via POST. Which ties back to my previous
>>> question: what measures (if any) are supposed to be taken by the xserver
>>> in order to hand over the legacy VGA ports to a secondary chipset that
>>> needs access to them for POST, when run with a different chipset as
>>> primary? As in, Savage is mapped to legacy VGA, I want to POST the Oak
>>> chipset, which needs a mapping to the VGA ports too, so what should the
>>> xserver do?
>> The bridge chipset needs to route vga to the proper card.  Pre-1.5
>> xservers used to handle this.  libpciaccess does not yet AFAIK.
>> Alex
> Then, this is technically a regression.
> So, lets say I want to add this support back. Is this squarely a
> libpciaccess change, or do I have to place this on the xserver (since
> this is specifically a VGA requirement)? Is anyone currently working on
> this, by any chance (just to avoid duplicating work). Any suggestions on
> the proper API to expose from libpciaccess? Are there any official docs
> on bridge chipsets, besides the actual source code of old xservers?

Ideally it would be done in the kernel to be used with libpciaccess.
Tiago and Paulo have been working on it:
I'm not sure what the current status is.  As for documents, your best
bet is probably hw reference guides from the vendors who make the PCI
chipsets (AMD/VIA/Intel/etc.).  Most are available.


More information about the xorg mailing list