On 2019/06/21, Koenig, Christian wrote: > Am 21.06.19 um 13:58 schrieb Emil Velikov: > > On 2019/06/21, Koenig, Christian wrote: > >> Am 21.06.19 um 12:53 schrieb Emil Velikov: > >>> On 2019/06/21, Koenig, Christian wrote: > >>>> [SNIP] > >>>> Well partially. That RADV broke is unfortunate, but we have done so many > >>>> customized userspace stuff both based on Mesa/DDX as well as closed > >>>> source components that it is just highly likely that we would break > >>>> something else as well. > >>>> > >>> As an engineer I like to work with tangibles. The highly likely part is > >>> probable, but as mentioned multiple times the series allows for a _dead_ > >>> trivial way to address any such problems. > >> Well to clarify my concern is that this won't be so trivial. > >> > >> You implemented on workaround for one specific case and it is perfectly > >> possible that for other cases we would have to completely revert the > >> removal of DRM_AUTH. > >> > > I would encourage you to take a closer look at my patch and point out > > how parcicular cases cannot be handled. > > Well the last time I looked it only blocked the first call to the IOCTL. > Hmm interesting, you're replied to my patch without even reading it :'-( Can you please give it a close look and reply inline? [1] https://lists.freedesktop.org/archives/dri-devel/2019-May/219238.html > > From your experiense, do user-space developers care about doing (or > > generally do) the right thing? > > No, not at all. Except for Marek and Michel they just take what works > and even Marek is often short-cutting on this. > Interesting, guess I should have asked this question from the start. Thanks Emil _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx