On Thu, May 28, 2015 at 10:22 AM, Emil Velikov emil.l.velikov@gmail.com wrote:
Hi Alex,
On 28 May 2015 at 14:16, Alex Deucher alexdeucher@gmail.com wrote:
On Thu, May 28, 2015 at 8:44 AM, Emil Velikov emil.l.velikov@gmail.com wrote:
On 25 May 2015 at 12:18, Zhou, Jammy Jammy.Zhou@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 ?
Sure, go for it. Jammy or Frank might be able to provide some pseudo code in the interim.
Alex
Thanks Emil