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

[Thomas Hellstrom]

On 02/24/2017 08:13 AM, Daniel Vetter wrote:
> 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.

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