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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 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.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux