Matthias Hopf wrote:

On May 01, 09 14:13:48 +0200, Florian Forster wrote:

...

The variable `enable_device' is only declared when libpciaccess is used, but only read if libpciaccess is *not* available.

I have to admit I have *no idea* what `pci_device_enable' does, but from the rest of the 9ad3554c commit I guess this is what was intended.

Yes, fixed and committed this already before I read your mail :)

Oh, that was my silly mistake. Because the version that doesn't use libpciaccess fails to work on my architecture I didn't test it without libpciaccess, but I now realise that I could've and should've compile tested it, even though I can't run it. BTW, the pci_device_enable() function on the Linux OS writes a "1" to the enable file in the sysfs directory of the specified card. The kernel docs say that this enables the card (if it wasn't enabled before) and increments the enable count by one. Writing a zero to the enable file decrements the enable count, so that a read of enable returns the number of ones written to it less the number of zeros written to it. When sufficient zeros are written the enable file decrements to zero and the card is disabled, but not fully, since some of the initialisation cannot be reversed. Most (all?) people should not need to use the '-e' option to rhd_dump and rhd_conntest. There have been reports by a few people that they do need to manually enable their display card (particularly secondary display cards) so I provided the option to call pci_device_enable() in rhd_dump/rhd_conntest. It would be interesting to hear from someone so affected whether the '-e' option works if they run rhd_dump/rhd_conntest before otherwise enabling the display card. This would provide evidence that a call to pci_device_enable() should be in the radeonhd driver. The last time I looked it wasn't; in contrast the radeon driver does call pci_device_enable() but quite late in the initialisation code which surprised me -- I wonder if it works! Some people have also reported that on using a secondary display card that radeonhd reads the BIOS of the wrong card. It would be interesting to hear from those making such reports whether running the updated rhd_conntest with the '-r' option reads the BIOS of the specified card (whether primary or secondary). I haven't been able to test this (though I have recently thought of a way I might just be able to contrive a similar test.) Cheers Michael. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org