[PATCH] Add device enumeration interface (v3)

Emil Velikov emil.l.velikov at gmail.com
Thu May 28 07:22:47 PDT 2015

Hi Alex,

On 28 May 2015 at 14:16, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Thu, May 28, 2015 at 8:44 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 25 May 2015 at 12:18, Zhou, Jammy <Jammy.Zhou at amd.com> wrote:
>>> Hi Emil,
>>> Do you have chance to have a look at this new version? Thanks!
>> Hi guys sorry for the delay.
>> Looking at my original email response it seems that I wasn't clear
>> enough about my concerns. They can be looked at as independent and/or
>> grouped up, depending on your liking:
>> - Adding a new interface using which it's not obvious how one can
>> simplify/ease existing related implementations.
>> As mentioned before, the claiming duplication that already exists is
>> more complete than this API.
>> - No open-source software uses the interface.
>> Do you have any patches in progress that convert project foo to using
>> the API? Otherwise is seems like an open-source project catering after
>> a closed source project needs.
> It's actually in preparation for upcoming open source releases.
Ack. Fair enough - the commit message did not mention any open source
users. The follow-up response mentioned xserver and mesa for which
this API doesn't seem like a good fit.

>> - Adding new dependencies.
>> Previously libpciaccess, now libudev. The former is used only by a
>> single function in libdrm_intel, while the latter was optional. v3
>> makes the use of libudev a hard requirement.
>> Using the library in mesa has caused problems with Steam (and possibly
>> other binary programs/games) which ships their own version of various
>> libraries.
> Can you think of a better method for device enumeration?  Rolling our
> own seem like a waste of effort.
Implementation might be uglier (as do other parts of libdrm), but I
can envision an API that does not require a new dependency, plus it
works with platform devices. So I'm not sure if it qualifies as better
or not.

>> Now that the patch is merged, the last issue has emerged (in a
>> particular form). Is there any plan to convert an open-source project
>> to use this API ?
> The first users actually will be open source they are just not ready
> for public release just yet.  We are trying to reduce our internal
> patch queue and get stuff upstream early and thought others might be
> interested, but if there are concerns we can revert it for now and
> re-submit it when we are ready to release the relevant code.
If you can share some pseudo code on what the requirements are/how it
should be used I can prep an alternative solution. A one that works
for your usecase and existing ones. In the mean while can we revert
it, pretty please ?


More information about the dri-devel mailing list