Device enumeration support in libdrm
Dropping dri-devel for a second.
Hi Jammy,
On 10 July 2015 at 18:56, Emil Velikov wrote:
> On 9 July 2015 at 03:26, Zhou, Jammy wrote:
>> Although I don't like the method of manually iterating sysfs, it seems the
>> last resort if we want to avoid introducing libudev dependency.
>>
> I have the same feeling, so if anyone can come with an better solution
> I'm all ears.
>
>> Besides, you mentioned that you would spend some time on the device
>> enumeration interface, do you have some chance to look at it?
>>
> Not really bth. Waiting for a month someone to ack the revert inspired
> me to push this at the bottom on my list. Now that there is some
> interest I'll bring it back up.
>
I've been looking at this over the last few days, aiming for a
compatible solution and it has been proving a bit annoying. Mostly due
to the way any platform devices interact with the UNIQUE ioctls.
Namely the goal is to have drmGetDevices() provide bus information
that can be used with conjunction with drmOpen and (optionally)
drmGetBusid.
Can you help me out, understand how you're going to be using this,
such that I don't butcher things.
In what formal should the bus information be - are your intentions
solely on feeding that to drmOpen() or is the user going to do
something with it ?
Would providing the vendor/device id (via drmGetDevices) suffice or
you guys need the sub{vendor,device} rev as well ?
Thanks
Emil
Device enumeration support in libdrm
On 9 July 2015 at 03:26, Zhou, Jammy wrote: > Although I don't like the method of manually iterating sysfs, it seems the > last resort if we want to avoid introducing libudev dependency. > I have the same feeling, so if anyone can come with an better solution I'm all ears. > Besides, you mentioned that you would spend some time on the device > enumeration interface, do you have some chance to look at it? > Not really bth. Waiting for a month someone to ack the revert inspired me to push this at the bottom on my list. Now that there is some interest I'll bring it back up. -Emil
Device enumeration support in libdrm
Although I don't like the method of manually iterating sysfs, it seems the last resort if we want to avoid introducing libudev dependency. Besides, you mentioned that you would spend some time on the device enumeration interface, do you have some chance to look at it? Regards, Jammy -Original Message- From: Emil Velikov [mailto:emil.l.veli...@gmail.com] Sent: Thursday, July 09, 2015 12:25 AM To: Zhou, Jammy Cc: dri-devel at lists.freedesktop.org Subject: Re: Device enumeration support in libdrm Hello Jammy, On 8 July 2015 at 06:53, Zhou, Jammy wrote: > Hi Emil, > > > > With our previous RFC patches to add interfaces to support GPU device > enumeration support in libdrm, the udev mechanism was used. But we > found that if we introduce the libudev dependency for libdrm, there > will be some problem to run steam application on recent distributions > (for example, Ubuntu 14.04 LTS) because of the conflict between the > system libudev.so.1 (loaded by libdrm) and the libudev.so.0 (bundled > in steam-runtime and loaded by steam application). There are some > similar issues as mentioned in the links below. Although we can argue > that it is applicationâs problem, can we get rid of libudev for the > device enumeration before Valve can make steam-runtime use system > libraries by default? It is much appreciated if you can give some > suggestions about how we can support device enumeration with libdrm. > I believe I mentioned it before, perhaps I wasn't clear enough. Rather than using libudev, manually iterate through sysfs. I agree it's not a not pretty solution yet the libdrm code already has much weirder stuff. Cheers Emil
Device enumeration support in libdrm
Hello Jammy, On 8 July 2015 at 06:53, Zhou, Jammy wrote: > Hi Emil, > > > > With our previous RFC patches to add interfaces to support GPU device > enumeration support in libdrm, the udev mechanism was used. But we found > that if we introduce the libudev dependency for libdrm, there will be some > problem to run steam application on recent distributions (for example, > Ubuntu 14.04 LTS) because of the conflict between the system libudev.so.1 > (loaded by libdrm) and the libudev.so.0 (bundled in steam-runtime and loaded > by steam application). There are some similar issues as mentioned in the > links below. Although we can argue that it is applicationâs problem, can we > get rid of libudev for the device enumeration before Valve can make > steam-runtime use system libraries by default? It is much appreciated if you > can give some suggestions about how we can support device enumeration with > libdrm. > I believe I mentioned it before, perhaps I wasn't clear enough. Rather than using libudev, manually iterate through sysfs. I agree it's not a not pretty solution yet the libdrm code already has much weirder stuff. Cheers Emil
Device enumeration support in libdrm
Hi Emil, With our previous RFC patches to add interfaces to support GPU device enumeration support in libdrm, the udev mechanism was used. But we found that if we introduce the libudev dependency for libdrm, there will be some problem to run steam application on recent distributions (for example, Ubuntu 14.04 LTS) because of the conflict between the system libudev.so.1 (loaded by libdrm) and the libudev.so.0 (bundled in steam-runtime and loaded by steam application). There are some similar issues as mentioned in the links below. Although we can argue that it is application's problem, can we get rid of libudev for the device enumeration before Valve can make steam-runtime use system libraries by default? It is much appreciated if you can give some suggestions about how we can support device enumeration with libdrm. https://wiki.debian.org/Steam https://github.com/ValveSoftware/steam-runtime/issues/13 Regards, Jammy -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150708/0d5e8e73/attachment-0001.html>
