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

[Daniel Vetter]

On Fri, Feb 24, 2017 at 7:44 AM, Thomas Hellstrom <thellstrom at 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 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?

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch