> Date: Wed, 14 Aug 2013 20:15:43 +0200 > From: Egbert Eich <[email protected]> > > On Wed, Aug 14, 2013 at 07:50:50PM +0200, Mark Kettenis wrote: > > > From: Egbert Eich <[email protected]> > > > Date: Wed, 14 Aug 2013 18:17:02 +0200 > > > > > > Primary PCI devices are identified by checking for an 'PCIINFOCLASSES' > > > device which is VGA and has access to the memory bars enabled. > > > If there should be more than one device for which this is true > > > redo the check and also check if IO resoures are also enabled, > > > if this still doesn't turn up a unique result also check for > > > the presence of a BIOS rom. > > > > Assuming this is a patch carried by SuSE, I'm a little bit surprised > > this is needed. These days the primary VGA device should be detected > > by libpciaccess through the pci_device_is_boot_vga() call, and I > > believe the detection code in xf86pciBus.c should only be hit if that > > method isn't implemented in libpciaccess. But for Linux > > pci_device_is_boot_vga() is implemented. > > > > Like the two patches for ACPI support I've sent today, it is not > needed for the Xserver we ship today. However for an enterprise > product with long term support this patch was needed and still is > to fix a real problem that has been observed out in the field. > > Since the code that's being fixed still exists I believe there > is still some value in integrating this - unless we decide to > drop this code entirely. (Same is true for the ACPI support fixes).
I think dropping this non-libpciaccess fallback codepath should be the goal. Currently of all the systems supported by libpciaccess, only FreeBSD and OpenBSD don't implement the "oot_vga" callback function. And I've got the OpenBSD code written, which I'll send back upstream once our KMS support stabilizes a bit. So I fear you're just adding dead code here. My suggestion would be to simply drop this diff. But I won't object if others chime in and think this diff still has value. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
