[PATCH] drm/vmwgfx: Work around drm removal of control nodes

[Thomas Hellstrom]

On 02/22/2017 08:04 PM, Daniel Vetter wrote:
> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom
> <thellstrom at 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 at vger.kernel.org>
>> Signed-off-by: Thomas Hellstrom <thellstrom at 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 at 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= 
>
>