Hi Alex, On 28 May 2015 at 14:16, Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > On Thu, May 28, 2015 at 8:44 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >> On 25 May 2015 at 12:18, Zhou, Jammy <Jammy.Zhou@xxxxxxx> 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 ? Thanks Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
