[PATCH libdrm] xf86drm: Parse the separate files to retrieve the vendor/device info

[Emil Velikov]

On 2 November 2016 at 11:14, Peter Wu <peter at lekensteyn.nl> wrote:
> On Tue, Nov 01, 2016 at 06:13:34PM +0000, Emil Velikov wrote:
>>  sysfs file wakes up the device. The latter of which may
>> be slow and isn't required to begin with.
>>
>> Reading through config is/was required since the revision is not
>> available by other means, although with a kernel patch in the way we can
>> 'cheat' temporarily.
>>
>> That should be fine, since no open-source project has ever used the
>> value.
>>
>> Cc: Michel Dänzer <michel.daenzer at amd.com>
>> Cc: Mauro Santos <registo.mailling at gmail.com>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>> Signed-off-by: Emil Velikov <emil.velikov at collabora.com>
>
> See below for one observation. Other than that, strace confirms that
> the new sysfs files are being accessed.
>
> Reviewed-and-tested-by: Peter Wu <peter at lekensteyn.nl>
>
> This was tested with Linux 4.8.4 (unpatched) and libdrm 2.4.71 (+this
> patch) with i915 + nouveau. Tested with running glxgears and glxinfo.
> Note that glxinfo still accesses 'config' due to libpciaccess.
>
> + drm_intel_get_aperture_sizes
>   + drm_intel_probe_agp_aperture_size
>     + pci_system_init()
>       + pci_system_linux_sysfs_create
>         + populate_entries
>           + pci_device_linux_sysfs_read() <-- offending function
>     + pci_device_find_by_slot(0, 0, 2, 0)
>
> That populate_entries function can probably use a fix similar to this
> one.
>
Indeed it would, although we ought to check if that won't cause any
(extra) regressions.

Skimming through my distro (Arch) the following depend on libpciaccess:

intel-gpu-tools
libdrm
libvirt
radeontool
spice-vdagent
vbetool
xorg-server

Of which the first two are safe, while the last one isn't + it even
exports the revision to DDX via xf86str.h's GDevRec::chipRev
Which gives us even more places to check through. Can you lend a hand ?

Thanks
Emil