Hi Emil, Sorry for the delay, finally coming back to this after my vacation. Am 03.07.19 um 17:14 schrieb Emil Velikov: > On Wed, 3 Jul 2019 at 15:58, Koenig, Christian <Christian.Koenig@xxxxxxx> wrote: >> Am 03.07.2019 16:51 schrieb Emil Velikov <emil.l.velikov@xxxxxxxxx>: >> >> On Wed, 3 Jul 2019 at 15:33, Koenig, Christian <Christian.Koenig@xxxxxxx> wrote: >>> Am 03.07.2019 16:00 schrieb Emil Velikov <emil.l.velikov@xxxxxxxxx>: >>> >>> On Wed, 3 Jul 2019 at 14:48, Koenig, Christian <Christian.Koenig@xxxxxxx> wrote: >>>> Well this is still a NAK. >>>> >>>> As stated previously please just don't remove DRM_AUTH and keep the functionality as it is. >>>> >>> AFAICT nobody was in favour of your suggestion to remove DRM_AUTH from >>> the handle to/from fd ioclts. >>> Thus this seems like the second best option. >>> >>> >>> Well just keep it. As I said please don't change anything here. >>> >>> Dropping DRM_AUTH from the driver IOCTLs was sufficient to work around the problems at hand far as I know. >>> >> We also need the DRM_AUTH for handle to/from fd ones. Mesa drivers use >> those ioctls. >> >> >> Yeah, but only for importing/exporting things. >> >> And in those cases we either already gave render nodes or correctly authenticated primary nodes. >> >> So no need to change anything here as far as I see. >> > Not quite. When working with the primary node we have the following scenarios: > - handle to fd -> pass fd to other APIs - gbm, opencl, vdpau, etc > - handle to fd -> fd to handle - use it internally Yeah, but this would once more mean that we expose the same functionality on the primary node we do on the render node. And that is exactly what I want to prevent, because I think it is a very bad idea and will result in basically deprecating the render node. For the problem at hand it was sufficient to drop the DRM_AUTH flag from the driver IOCTLs and I don't see a reason why we should go further than this. Please just completely drop this whole approach, Christian. > > -Emil _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
