Hi Rob, On Thu, Apr 12, 2018 at 12:56 PM Robert Foss <robert.foss@xxxxxxxxxxxxx> wrote: > *Resend the whole actual series* > This patch implements a simple function for matching DRM device FDs against > the desired properties of a device that you are looking for. > The properties that are possible to look for are the elements of DrmVersion > and DrmDevice. > The discussion that led to this series can be found here: > https://lists.freedesktop.org/archives/mesa-dev/2018-January/183878.html > In the previous discussion we left off having settled on implementing this > in mesa/src/loader/loader.c, which I initially did. But the code ended up being > so generic that there's no reason for it not to live in libdrm, since it can be > used for any compositor and mesa. > The implementer will still have to iterate through all of the devices available > on the target, and see if they match. This additional functionality could be > moved into libdrm at a later point if it turns out that all of the users do this > in the same manner. > If there is some variety, for example with selecting fallback devices if nothing > matches maybe it is best left up to the user of libdrm. > The biggest problem with the approach as implemented, the way I see it, is how > we match against the DrmVersion/DrmDevice of a given FD. > Currently we use DrmVersion & DrmDevice as supplied by the caller to define what > we are looking for. > This is a little bit problematic, especially for DrmDevice, since all of the > elements of the struct do not have enough bitspace to signal that we are > uninterested in looking for that specific element. DrmDevice uses > drmDevicesEqual() to do what amounts to a memcmp of the DrmDevice argument and > the one of the FD. So looking for any device on any PCI bus with just the > PCI vendor ID supplied isn't possible. > An alternative Daniel Stone suggested is adding enums for different properties > and allowing the caller to supply a list of properties that are interesting and > their values. In terms of long-term maintainership this might be less pleasant > than the approach of the current implementation. I'm personally okay with how patch 1 implements the matching. Thanks for this work. Looking forward to the Mesa probing helper, which uses this! :) P.S. I normally use my @chromium.org email for mailing lists. Best regards, Tomasz _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
