Re: Using wsdisplay from the Xserver

>> PCI_IOC_CFGREAD
> That's an interface which is already there and used by X.
That's the problem. X has no business dealing with the level of PCI
config registers; that's for the PCI attachment code for the graphics
hardware to deal with. See also below.
> Why reinvent the wheel?
Because the one that's there is the wrong wheel. The X server should
be telling the driver "give me the $FOO registers", not mucking about
with PCI config itself. What if the attachment the chip is behind
isn't PCI? Userland shouldn't care about that any more than it cares
about whether a file is on a bha-attached Seagate drive or a
Firewire-attached Western Digital drive.
>> the X server still knows about PCI directly
> It does, and so does every single PCI/AGP graphics chip driver.
For drivers, that makes sense; their PCI attachment code (often rolled
into the chip's driver if the chip is not known to exist in any other
form) is the right place for PCI knowledge.
As for the X server, well...
> There is absolutely nothing wrong with the Xserver knowing that it
> deals with PCI devices.
...this is the core point we disagree on. I see that as about as sane
as a serial comm program knowing it's talking to an ISA-attached 16550A
instead of an obio-attached z8530 or a PCMCIA-attached pcmcom. Drivers
exist to hide that sort of thing, because userland has no business
anywhere near it.
> Accessing a graphics chip's config space is ok in my book and indeed
> necessary.
The _graphics chip_'s config space, yes. But this is the _PCI_ config
space. (If the card is weird enough to keep some/all of its graphics
chip configuration in PCI config space rather than PCI I/O space,
that's an implementation botch for the device driver to deal with when
userland asks for the chip's config registers.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B