On Wed, Apr 17, 2019 at 12:06:32PM +0000, Koenig, Christian wrote: > Am 17.04.19 um 14:00 schrieb Daniel Vetter: > > On Wed, Apr 17, 2019 at 11:18:35AM +0000, Koenig, Christian wrote: > >> Am 17.04.19 um 13:06 schrieb Daniel Vetter: > >>> On Wed, Apr 17, 2019 at 12:29 PM Koenig, Christian > >>> <christian.koe...@amd.com> wrote: > >>> [SNIP] > >> Well, what you guys did here is a serious no-go. > > Not really understanding your reasons for an unconditional nak on all this > > still. > > Well, let me summarize: You worked around a problem with libva by > breaking another driver and now proposing a rather ugly and only halve > backed workaround for that driver. > > This is a serious no-go. I've already send out a i915 specific change to > remove DRM_AUTH from IOCTLs which also have DRM_RENDER_ALLOW and revert > the offending patch.
Oh I'm totally fine with the revert if that's what we go with. But that still leaves the issue that it would make sense to drop DRM_AUTH from DRIVER_RENDER capable drivers (not just for libva, but in general). And there's fundamentally 2 options to do that: - This one here (or anything implementing the same idea), to keep radv working. - We drop DRM_AUTH from all drivers with DRIVER_RENDER except amdgpu. How exactly that's doen doesn't matter, but it leaves amdgpu out in the cold. It also doesn't matter whether we get there with revert + lots of patches, or a special hack for amdgpu, in the end amdgpu would be different. Also note that your patch isn't enough, since it doesn't fix the core ioctls. I think from an overall platform pov, the first is the better option. After all we try really hard to avoid driver special cases for these kinds of things. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
