| Message ID | 20170221104227.2854-1-thellstrom@vmware.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Reviewed-by: Sinclair Yeh <syeh@vmware.com> On Tue, Feb 21, 2017 at 05:42:27PM +0700, Thomas Hellstrom wrote: > vmware tools has a daemon that gets layout information from the GUI and > forwards it to DRM so that the modesetting code can set preferred connector > locations and modes. This daemon was using control nodes but since control > nodes were just removed, make it possible for the daemon to use render- or > primary nodes instead. This is a bit ugly but will allow drm to proceed with > removal of the mostly unused control-node code and allow vmware to proceed > with fixing up automatic layout settings for gnome-shell/wayland. > > We bump minor to inform user-space about the api change. > > Cc: <stable@vger.kernel.org> > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> > --- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++++++++++- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- > 2 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > index 541a588..d08f269 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = { > VMW_IOCTL_DEF(VMW_PRESENT_READBACK, > vmw_present_readback_ioctl, > DRM_MASTER | DRM_AUTH), > + /* > + * The permissions of the below ioctl are overridden in > + * vmw_generic_ioctl(). We require either > + * DRM_MASTER or capable(CAP_SYS_ADMIN). > + */ > VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT, > vmw_kms_update_layout_ioctl, > - DRM_MASTER | DRM_CONTROL_ALLOW), > + DRM_RENDER_ALLOW), > VMW_IOCTL_DEF(VMW_CREATE_SHADER, > vmw_shader_define_ioctl, > DRM_AUTH | DRM_RENDER_ALLOW), > @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, unsigned int cmd, > > return (long) vmw_execbuf_ioctl(dev, arg, file_priv, > _IOC_SIZE(cmd)); > + } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) { > + if (!drm_is_current_master(file_priv) && > + !capable(CAP_SYS_ADMIN)) > + return -EACCES; > } > > if (unlikely(ioctl->cmd != cmd)) > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > index 1e59a48..59ff419 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > @@ -41,9 +41,9 @@ > #include <drm/ttm/ttm_module.h> > #include "vmwgfx_fence.h" > > -#define VMWGFX_DRIVER_DATE "20160210" > +#define VMWGFX_DRIVER_DATE "20170221" > #define VMWGFX_DRIVER_MAJOR 2 > -#define VMWGFX_DRIVER_MINOR 11 > +#define VMWGFX_DRIVER_MINOR 12 > #define VMWGFX_DRIVER_PATCHLEVEL 0 > #define VMWGFX_FILE_PAGE_OFFSET 0x00100000 > #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) > -- > 2.9.3 >
On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote: > vmware tools has a daemon that gets layout information from the GUI and > forwards it to DRM so that the modesetting code can set preferred connector > locations and modes. This daemon was using control nodes but since control > nodes were just removed, make it possible for the daemon to use render- or > primary nodes instead. This is a bit ugly but will allow drm to proceed with > removal of the mostly unused control-node code and allow vmware to proceed > with fixing up automatic layout settings for gnome-shell/wayland. > > We bump minor to inform user-space about the api change. > > Cc: <stable@vger.kernel.org> > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Seems reasonable. I guess with hindsight we probably should have added a virtual_x/y hint, similar to the hotpsot hinting we do for cursors. But since vmwgfx is the only virtual gpu that seems to do multi-screen that need was never all that apparent. I think we should fix that if/when vmwgfx switches over to atomic, atomic is super easy to extend. Also, with this patch I think we can restore backwards compat by registering the render node as controlD (but only for vmwgfx, we'll keep the fake symlink for everyone else). I'm travelling still till the end of this week, and my brain is wrecked, but will get to that as soon as I'm back next week. I'll also reference the link in that commit. Cheers, Daniel > --- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++++++++++- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- > 2 files changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > index 541a588..d08f269 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = { > VMW_IOCTL_DEF(VMW_PRESENT_READBACK, > vmw_present_readback_ioctl, > DRM_MASTER | DRM_AUTH), > + /* > + * The permissions of the below ioctl are overridden in > + * vmw_generic_ioctl(). We require either > + * DRM_MASTER or capable(CAP_SYS_ADMIN). > + */ > VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT, > vmw_kms_update_layout_ioctl, > - DRM_MASTER | DRM_CONTROL_ALLOW), > + DRM_RENDER_ALLOW), > VMW_IOCTL_DEF(VMW_CREATE_SHADER, > vmw_shader_define_ioctl, > DRM_AUTH | DRM_RENDER_ALLOW), > @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, unsigned int cmd, > > return (long) vmw_execbuf_ioctl(dev, arg, file_priv, > _IOC_SIZE(cmd)); > + } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) { > + if (!drm_is_current_master(file_priv) && > + !capable(CAP_SYS_ADMIN)) > + return -EACCES; > } > > if (unlikely(ioctl->cmd != cmd)) > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > index 1e59a48..59ff419 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > @@ -41,9 +41,9 @@ > #include <drm/ttm/ttm_module.h> > #include "vmwgfx_fence.h" > > -#define VMWGFX_DRIVER_DATE "20160210" > +#define VMWGFX_DRIVER_DATE "20170221" > #define VMWGFX_DRIVER_MAJOR 2 > -#define VMWGFX_DRIVER_MINOR 11 > +#define VMWGFX_DRIVER_MINOR 12 > #define VMWGFX_DRIVER_PATCHLEVEL 0 > #define VMWGFX_FILE_PAGE_OFFSET 0x00100000 > #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) > -- > 2.9.3 > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
On 02/22/2017 08:04 PM, Daniel Vetter wrote: > On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom > <thellstrom@vmware.com> wrote: >> vmware tools has a daemon that gets layout information from the GUI and >> forwards it to DRM so that the modesetting code can set preferred connector >> locations and modes. This daemon was using control nodes but since control >> nodes were just removed, make it possible for the daemon to use render- or >> primary nodes instead. This is a bit ugly but will allow drm to proceed with >> removal of the mostly unused control-node code and allow vmware to proceed >> with fixing up automatic layout settings for gnome-shell/wayland. >> >> We bump minor to inform user-space about the api change. >> >> Cc: <stable@vger.kernel.org> >> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> > Seems reasonable. So is this an Acked-by? > I guess with hindsight we probably should have added > a virtual_x/y hint, similar to the hotpsot hinting we do for cursors. > But since vmwgfx is the only virtual gpu that seems to do multi-screen > that need was never all that apparent. I think we should fix that > if/when vmwgfx switches over to atomic, atomic is super easy to > extend. Yes. I think we're open to a way to make this fit into the atomic infrastructure. We should remember though that other virtual GPUs may get this information from the virtual device rather than from user-space. The reason the information still originates from user-space in the VMware environment is the need to support remote screen layouts from a guest. > Also, with this patch I think we can restore backwards compat > by registering the render node as controlD (but only for vmwgfx, we'll > keep the fake symlink for everyone else). Actually, given that the feature was pulled out of the openSuSE and Fedora packages at the very last minute, it seems like we can skip the special VMware control node setup. The damage will be limited to within VMware. > I'm travelling still till > the end of this week, and my brain is wrecked, but will get to that as > soon as I'm back next week. I'll also reference the link in that > commit. > > Cheers, Daniel Thanks, Thomas > >> --- >> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++++++++++- >> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- >> 2 files changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c >> index 541a588..d08f269 100644 >> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c >> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c >> @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = { >> VMW_IOCTL_DEF(VMW_PRESENT_READBACK, >> vmw_present_readback_ioctl, >> DRM_MASTER | DRM_AUTH), >> + /* >> + * The permissions of the below ioctl are overridden in >> + * vmw_generic_ioctl(). We require either >> + * DRM_MASTER or capable(CAP_SYS_ADMIN). >> + */ >> VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT, >> vmw_kms_update_layout_ioctl, >> - DRM_MASTER | DRM_CONTROL_ALLOW), >> + DRM_RENDER_ALLOW), >> VMW_IOCTL_DEF(VMW_CREATE_SHADER, >> vmw_shader_define_ioctl, >> DRM_AUTH | DRM_RENDER_ALLOW), >> @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, unsigned int cmd, >> >> return (long) vmw_execbuf_ioctl(dev, arg, file_priv, >> _IOC_SIZE(cmd)); >> + } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) { >> + if (!drm_is_current_master(file_priv) && >> + !capable(CAP_SYS_ADMIN)) >> + return -EACCES; >> } >> >> if (unlikely(ioctl->cmd != cmd)) >> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h >> index 1e59a48..59ff419 100644 >> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h >> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h >> @@ -41,9 +41,9 @@ >> #include <drm/ttm/ttm_module.h> >> #include "vmwgfx_fence.h" >> >> -#define VMWGFX_DRIVER_DATE "20160210" >> +#define VMWGFX_DRIVER_DATE "20170221" >> #define VMWGFX_DRIVER_MAJOR 2 >> -#define VMWGFX_DRIVER_MINOR 11 >> +#define VMWGFX_DRIVER_MINOR 12 >> #define VMWGFX_DRIVER_PATCHLEVEL 0 >> #define VMWGFX_FILE_PAGE_OFFSET 0x00100000 >> #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) >> -- >> 2.9.3 >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=DwIBaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=vcENuMKTrk3-3q3adLKH-tLLJ7_eylT6C8xYUvaz4Uk&s=szfE_BhH3uP4zYt6YMTQfwYcndmHEXxRKrrja54qdG4&e= > >
On Fri, Feb 24, 2017 at 7:44 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote: > On 02/22/2017 08:04 PM, Daniel Vetter wrote: >> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom >> <thellstrom@vmware.com> wrote: >>> vmware tools has a daemon that gets layout information from the GUI and >>> forwards it to DRM so that the modesetting code can set preferred connector >>> locations and modes. This daemon was using control nodes but since control >>> nodes were just removed, make it possible for the daemon to use render- or >>> primary nodes instead. This is a bit ugly but will allow drm to proceed with >>> removal of the mostly unused control-node code and allow vmware to proceed >>> with fixing up automatic layout settings for gnome-shell/wayland. >>> >>> We bump minor to inform user-space about the api change. >>> >>> Cc: <stable@vger.kernel.org> >>> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> >> Seems reasonable. > > So is this an Acked-by? Sure. >> I guess with hindsight we probably should have added >> a virtual_x/y hint, similar to the hotpsot hinting we do for cursors. >> But since vmwgfx is the only virtual gpu that seems to do multi-screen >> that need was never all that apparent. I think we should fix that >> if/when vmwgfx switches over to atomic, atomic is super easy to >> extend. > > Yes. I think we're open to a way to make this fit into the atomic > infrastructure. We should remember though that other virtual GPUs may > get this information from the virtual device rather than from > user-space. The reason the information still originates from user-space > in the VMware environment is the need to support remote screen layouts > from a guest. Well not so much standardize it for atomic, but as a property. The upshot with atomic is simply that then the atomic core can decode the value and stuff it into drm_crtc_state for you, which seems to help a lot with standardizing it across drivers. If this is purely vmwgfx specific, then I guess we can leave it as-is, but my experience has been that these modeset special cases tend to not stay special forever. And now that I'm back from travelling and can look at things properly, we already have the standardized suggested_y/x/_property stuff, so for atomic I'd say definitely worth it to standardize this a bit. Maybe we need something like drm configuration properties, which are by default read-only, but can be written through sysfs? That way anyone could write them, as long as they can get at sysfs. And sysfs sounds like the more appropriate place to handle configuration stuff compared to some device ioctl. vmwgfx is probably not the only device that would need something like this, could be worth to standardize it a bit. >> Also, with this patch I think we can restore backwards compat >> by registering the render node as controlD (but only for vmwgfx, we'll >> keep the fake symlink for everyone else). > > Actually, given that the feature was pulled out of the openSuSE and > Fedora packages at the very last minute, it seems like we can skip the > special VMware control node setup. The damage will be limited to within > VMware. Awesome, if we can avoid baking in drm_control as abi for the next 10 years I'll be very happy. Thanks a lot for this quick change of plans on your side. Cheers, Daniel
On 02/24/2017 08:13 AM, Daniel Vetter wrote: > On Fri, Feb 24, 2017 at 7:44 AM, Thomas Hellstrom <thellstrom@vmware.com> wrote: >> On 02/22/2017 08:04 PM, Daniel Vetter wrote: >>> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom >>> <thellstrom@vmware.com> wrote: >>>> vmware tools has a daemon that gets layout information from the GUI and >>>> forwards it to DRM so that the modesetting code can set preferred connector >>>> locations and modes. This daemon was using control nodes but since control >>>> nodes were just removed, make it possible for the daemon to use render- or >>>> primary nodes instead. This is a bit ugly but will allow drm to proceed with >>>> removal of the mostly unused control-node code and allow vmware to proceed >>>> with fixing up automatic layout settings for gnome-shell/wayland. >>>> >>>> We bump minor to inform user-space about the api change. >>>> >>>> Cc: <stable@vger.kernel.org> >>>> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> >>> Seems reasonable. >> So is this an Acked-by? > Sure. > >>> I guess with hindsight we probably should have added >>> a virtual_x/y hint, similar to the hotpsot hinting we do for cursors. >>> But since vmwgfx is the only virtual gpu that seems to do multi-screen >>> that need was never all that apparent. I think we should fix that >>> if/when vmwgfx switches over to atomic, atomic is super easy to >>> extend. >> Yes. I think we're open to a way to make this fit into the atomic >> infrastructure. We should remember though that other virtual GPUs may >> get this information from the virtual device rather than from >> user-space. The reason the information still originates from user-space >> in the VMware environment is the need to support remote screen layouts >> from a guest. > Well not so much standardize it for atomic, but as a property. The > upshot with atomic is simply that then the atomic core can decode the > value and stuff it into drm_crtc_state for you, which seems to help a > lot with standardizing it across drivers. If this is purely vmwgfx > specific, then I guess we can leave it as-is, but my experience has > been that these modeset special cases tend to not stay special > forever. > > And now that I'm back from travelling and can look at things properly, > we already have the standardized suggested_y/x/_property stuff, so for > atomic I'd say definitely worth it to standardize this a bit. Maybe we > need something like drm configuration properties, which are by default > read-only, but can be written through sysfs? That way anyone could > write them, as long as they can get at sysfs. And sysfs sounds like > the more appropriate place to handle configuration stuff compared to > some device ioctl. vmwgfx is probably not the only device that would > need something like this, could be worth to standardize it a bit. Sure. > >>> Also, with this patch I think we can restore backwards compat >>> by registering the render node as controlD (but only for vmwgfx, we'll >>> keep the fake symlink for everyone else). >> Actually, given that the feature was pulled out of the openSuSE and >> Fedora packages at the very last minute, it seems like we can skip the >> special VMware control node setup. The damage will be limited to within >> VMware. > Awesome, if we can avoid baking in drm_control as abi for the next 10 > years I'll be very happy. Thanks a lot for this quick change of plans > on your side. > > Cheers, Daniel Thanks. Your work cleaning up DRM is very much appreciated. We don't want to get in the way if avoidable. /Thomas
On Tue, Feb 21, 2017 at 02:05:26PM -0800, Sinclair Yeh wrote: > Reviewed-by: Sinclair Yeh <syeh@vmware.com> Applied to drm-msic-next-fixes, I'll send the pull request asap. -Daniel > > > On Tue, Feb 21, 2017 at 05:42:27PM +0700, Thomas Hellstrom wrote: > > vmware tools has a daemon that gets layout information from the GUI and > > forwards it to DRM so that the modesetting code can set preferred connector > > locations and modes. This daemon was using control nodes but since control > > nodes were just removed, make it possible for the daemon to use render- or > > primary nodes instead. This is a bit ugly but will allow drm to proceed with > > removal of the mostly unused control-node code and allow vmware to proceed > > with fixing up automatic layout settings for gnome-shell/wayland. > > > > We bump minor to inform user-space about the api change. > > > > Cc: <stable@vger.kernel.org> > > Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> > > --- > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++++++++++- > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- > > 2 files changed, 12 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > index 541a588..d08f269 100644 > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c > > @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = { > > VMW_IOCTL_DEF(VMW_PRESENT_READBACK, > > vmw_present_readback_ioctl, > > DRM_MASTER | DRM_AUTH), > > + /* > > + * The permissions of the below ioctl are overridden in > > + * vmw_generic_ioctl(). We require either > > + * DRM_MASTER or capable(CAP_SYS_ADMIN). > > + */ > > VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT, > > vmw_kms_update_layout_ioctl, > > - DRM_MASTER | DRM_CONTROL_ALLOW), > > + DRM_RENDER_ALLOW), > > VMW_IOCTL_DEF(VMW_CREATE_SHADER, > > vmw_shader_define_ioctl, > > DRM_AUTH | DRM_RENDER_ALLOW), > > @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, unsigned int cmd, > > > > return (long) vmw_execbuf_ioctl(dev, arg, file_priv, > > _IOC_SIZE(cmd)); > > + } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) { > > + if (!drm_is_current_master(file_priv) && > > + !capable(CAP_SYS_ADMIN)) > > + return -EACCES; > > } > > > > if (unlikely(ioctl->cmd != cmd)) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > > index 1e59a48..59ff419 100644 > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h > > @@ -41,9 +41,9 @@ > > #include <drm/ttm/ttm_module.h> > > #include "vmwgfx_fence.h" > > > > -#define VMWGFX_DRIVER_DATE "20160210" > > +#define VMWGFX_DRIVER_DATE "20170221" > > #define VMWGFX_DRIVER_MAJOR 2 > > -#define VMWGFX_DRIVER_MINOR 11 > > +#define VMWGFX_DRIVER_MINOR 12 > > #define VMWGFX_DRIVER_PATCHLEVEL 0 > > #define VMWGFX_FILE_PAGE_OFFSET 0x00100000 > > #define VMWGFX_FIFO_STATIC_SIZE (1024*1024) > > -- > > 2.9.3 > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index 541a588..d08f269 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -199,9 +199,14 @@ static const struct drm_ioctl_desc vmw_ioctls[] = { VMW_IOCTL_DEF(VMW_PRESENT_READBACK, vmw_present_readback_ioctl, DRM_MASTER | DRM_AUTH), + /* + * The permissions of the below ioctl are overridden in + * vmw_generic_ioctl(). We require either + * DRM_MASTER or capable(CAP_SYS_ADMIN). + */ VMW_IOCTL_DEF(VMW_UPDATE_LAYOUT, vmw_kms_update_layout_ioctl, - DRM_MASTER | DRM_CONTROL_ALLOW), + DRM_RENDER_ALLOW), VMW_IOCTL_DEF(VMW_CREATE_SHADER, vmw_shader_define_ioctl, DRM_AUTH | DRM_RENDER_ALLOW), @@ -1123,6 +1128,10 @@ static long vmw_generic_ioctl(struct file *filp, unsigned int cmd, return (long) vmw_execbuf_ioctl(dev, arg, file_priv, _IOC_SIZE(cmd)); + } else if (nr == DRM_COMMAND_BASE + DRM_VMW_UPDATE_LAYOUT) { + if (!drm_is_current_master(file_priv) && + !capable(CAP_SYS_ADMIN)) + return -EACCES; } if (unlikely(ioctl->cmd != cmd)) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h index 1e59a48..59ff419 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h @@ -41,9 +41,9 @@ #include <drm/ttm/ttm_module.h> #include "vmwgfx_fence.h" -#define VMWGFX_DRIVER_DATE "20160210" +#define VMWGFX_DRIVER_DATE "20170221" #define VMWGFX_DRIVER_MAJOR 2 -#define VMWGFX_DRIVER_MINOR 11 +#define VMWGFX_DRIVER_MINOR 12 #define VMWGFX_DRIVER_PATCHLEVEL 0 #define VMWGFX_FILE_PAGE_OFFSET 0x00100000 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
vmware tools has a daemon that gets layout information from the GUI and forwards it to DRM so that the modesetting code can set preferred connector locations and modes. This daemon was using control nodes but since control nodes were just removed, make it possible for the daemon to use render- or primary nodes instead. This is a bit ugly but will allow drm to proceed with removal of the mostly unused control-node code and allow vmware to proceed with fixing up automatic layout settings for gnome-shell/wayland. We bump minor to inform user-space about the api change. Cc: <stable@vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 11 ++++++++++- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++-- 2 files changed, 12 insertions(+), 3 deletions(-)