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