[Intel-gfx] DRM_CONTROL node breakage (Re: [PATCH] [RFC] drm: Nerf DRM_CONTROL nodes)

[Thomas Hellstrom]

On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed testing this but you got to understand that not all
>> developer teams have a multitude of
>> developers (we have on average one for the whole linux graphics driver
>> stack except GL), and the bug
>> doesn't show up for QE on regression testing unless they run
>> gnome-sheel/Wayland which they currently don't, and I guess they've been
>> focused on the fb2 regression.
>>
>> It's no secret that we've been using the control nodes for some time.
>> The CONTROL_ALLOW is present in the
>> driver private ioctls and the commit has been there since 2016.
>>
>> The user-space code has been present in vmware-tools also since that
>> commit and due to the long release cycles of
>> open-vm-tools the open-vm-tools version was just about to be released.
>> It's necessary for non-xorg
> can you send a revert against drm-next? I'm not sure how clean it will be.
>
> there might be an intermediate step.
>
> Then can we port vmtools of this behaviour, not even sure what it is doing.
>
> Dave.

So after a quick investigation of the impact it looks like the daemon
patch was pulled out of the Fedora open-vm-tools update in time. This
limits the impact to within VMware where we can update the daemon code
and rerun the test cycle. I've posted a patch that makes it possible for
us to use render-nodes instead of control nodes.

/Thomas