Proper way to enable port access tracing with current xserver

[Alex Villací­s Lasso]

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?

-- 
perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'