On Fri, May 25, 2018 at 4:15 AM, Robert Foss <robert.f...@collabora.com> wrote: > > > On 2018-05-25 10:38, Tomasz Figa wrote: >> >> On Fri, May 25, 2018 at 5:33 PM Robert Foss <robert.f...@collabora.com> >> wrote: >> >>> Hey, >> >> >>> On 2018-05-25 02:17, Rob Herring wrote: >>>> >>>> On Thu, May 24, 2018 at 6:23 AM, Robert Foss <robert.f...@collabora.com> >> >> wrote: >>>>> >>>>> Hey, >>>>> >>>>> I don't think I've received any feedback on this version yet. >>>>> If anyone has some time to spare, it would be nice to get it merged. >>>>> >>>>> Just to be clear about the libdrm branch linked in the cover letter, >>>>> it is not required. Only for virgl platforms which happens to be what >>>>> I tested on. >>>> >>>> >>>> virgl will still fallback to using the first render node without those >>>> libdrm changes, right? If not, I don't think we should apply until >>>> we're not breaking a platform... >> >> >>> No it will not fall back. I agree that holding off makes more sense. >> >> >> What's the reason of this problems? Is it because of drmGetDevices()? >> Since >> we don't really use it for anything other than getting the list of render >> nodes in the system, maybe we could just iterate over any /dev/renderD* >> nodes explicitly and avoid introducing new problems? > > > That's exactly the problem, and yes we could 100% solve by iterating over > /dev/renderD* nodes. I originally assumed we wouldn't want to do that, but > rather use the libdrm interfaces. > > But for the next spin I could avoid using libdrm, should I?
I don't have an opinion on libdrm really, but I do think we should fallback to the 1st (only) render node rather than just fail. Rob _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
