On Thu, May 28, 2015 at 10:22 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > 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 ? Sure, go for it. Jammy or Frank might be able to provide some pseudo code in the interim. Alex > > Thanks > Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
