| Message ID | 1441798946-26233-6-git-send-email-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 9 September 2015 at 12:42, Gerd Hoffmann <kraxel@redhat.com> wrote: > From: Dave Airlie <airlied@redhat.com> > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > --- > drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > index 1245d09..e00298e 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > @@ -113,7 +113,7 @@ static const struct file_operations virtio_gpu_driver_fops = { > > > static struct drm_driver driver = { > - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME, > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | DRIVER_RENDER, I believe that this will only create the renderD# node. Shouldn't one also tag the relevant ioctls with DRM_RENDER_ALLOW ? Regards, Emil
On Do, 2015-09-10 at 09:59 +0100, Emil Velikov wrote: > On 9 September 2015 at 12:42, Gerd Hoffmann <kraxel@redhat.com> wrote: > > From: Dave Airlie <airlied@redhat.com> > > > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> > > --- > > drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c > > index 1245d09..e00298e 100644 > > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c > > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c > > @@ -113,7 +113,7 @@ static const struct file_operations virtio_gpu_driver_fops = { > > > > > > static struct drm_driver driver = { > > - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME, > > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | DRIVER_RENDER, > > I believe that this will only create the renderD# node. Shouldn't one > also tag the relevant ioctls with DRM_RENDER_ALLOW ? Dave? Looking at the ioctls they are all fine for render nodes, there isn't anything modesetting related in the device-specific ioctls. Correct? cheers, Gerd
On 10 September 2015 at 15:23, Gerd Hoffmann <kraxel@redhat.com> wrote: > On Do, 2015-09-10 at 09:59 +0100, Emil Velikov wrote: >> On 9 September 2015 at 12:42, Gerd Hoffmann <kraxel@redhat.com> wrote: >> > From: Dave Airlie <airlied@redhat.com> >> > >> > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> >> > --- >> > drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c >> > index 1245d09..e00298e 100644 >> > --- a/drivers/gpu/drm/virtio/virtgpu_drv.c >> > +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c >> > @@ -113,7 +113,7 @@ static const struct file_operations virtio_gpu_driver_fops = { >> > >> > >> > static struct drm_driver driver = { >> > - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME, >> > + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | DRIVER_RENDER, >> >> I believe that this will only create the renderD# node. Shouldn't one >> also tag the relevant ioctls with DRM_RENDER_ALLOW ? > > Dave? Looking at the ioctls they are all fine for render nodes, there > isn't anything modesetting related in the device-specific ioctls. > > Correct? > Unless I've overdone the coffee this time - modesetting is done via the card# node, while render via either card# or renderD#. So I'm suspecting that you're using card# node which would explain why things work. Otherwise drm_ioctl_permit will bail out with -EACCESS. Regards, Emil
Hi, > > Dave? Looking at the ioctls they are all fine for render nodes, there > > isn't anything modesetting related in the device-specific ioctls. > > > > Correct? > > > Unless I've overdone the coffee this time - modesetting is done via > the card# node, while render via either card# or renderD#. Exactly, thats why anything modesetting-related must be disabled for renderD#. Looking at the virtio-gpu device-specific ioctls I don't think there is anything doing modesetting (which we would have to leave out), so we can apply DRM_RENDER_ALLOW everythere I think. Or maybe there is a global switch to flip DRM_RENDER_ALLOW for the whole list ... cheers, Gerd
On 10 September 2015 at 15:52, Gerd Hoffmann <kraxel@redhat.com> wrote: > Hi, > >> > Dave? Looking at the ioctls they are all fine for render nodes, there >> > isn't anything modesetting related in the device-specific ioctls. >> > >> > Correct? >> > >> Unless I've overdone the coffee this time - modesetting is done via >> the card# node, while render via either card# or renderD#. > > Exactly, thats why anything modesetting-related must be disabled for > renderD#. Looking at the virtio-gpu device-specific ioctls I don't > think there is anything doing modesetting (which we would have to leave > out), so we can apply DRM_RENDER_ALLOW everythere I think. Or maybe > there is a global switch to flip DRM_RENDER_ALLOW for the whole list ... > IMHO the idea of having a 'global' switch sounds quite good, yet there isn't one atm :-( It will be quite useful as we get more render only devices. DRIVER_RENDER doesn't do that unfortunately (which I think was the original assumption), it only instructs drm core to create the renderD# device/node. Hope this clears up any ambiguity from my earlier replies :-) Emil
On 11 September 2015 at 01:04, Emil Velikov <emil.l.velikov@gmail.com> wrote: > On 10 September 2015 at 15:52, Gerd Hoffmann <kraxel@redhat.com> wrote: >> Hi, >> >>> > Dave? Looking at the ioctls they are all fine for render nodes, there >>> > isn't anything modesetting related in the device-specific ioctls. >>> > >>> > Correct? >>> > >>> Unless I've overdone the coffee this time - modesetting is done via >>> the card# node, while render via either card# or renderD#. >> >> Exactly, thats why anything modesetting-related must be disabled for >> renderD#. Looking at the virtio-gpu device-specific ioctls I don't >> think there is anything doing modesetting (which we would have to leave >> out), so we can apply DRM_RENDER_ALLOW everythere I think. Or maybe >> there is a global switch to flip DRM_RENDER_ALLOW for the whole list ... >> > IMHO the idea of having a 'global' switch sounds quite good, yet there > isn't one atm :-( It will be quite useful as we get more render only > devices. > DRIVER_RENDER doesn't do that unfortunately (which I think was the > original assumption), it only instructs drm core to create the > renderD# device/node. doh, yes we need to add DRM_RENDER_ALLOW to the ioctls, can you do that? Dave.
On Fr, 2015-09-11 at 16:32 +1000, Dave Airlie wrote: > doh, yes we need to add DRM_RENDER_ALLOW to the ioctls, can you do > that? Done. cheers, Gerd
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c b/drivers/gpu/drm/virtio/virtgpu_drv.c index 1245d09..e00298e 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.c +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c @@ -113,7 +113,7 @@ static const struct file_operations virtio_gpu_driver_fops = { static struct drm_driver driver = { - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME, + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME | DRIVER_RENDER, .set_busid = drm_virtio_set_busid, .load = virtio_gpu_driver_load, .unload = virtio_gpu_driver_unload,