On Fri, Feb 24, 2017 at 7:44 AM, Thomas Hellstrom <thellstrom@xxxxxxxxxx> wrote: > On 02/22/2017 08:04 PM, Daniel Vetter wrote: >> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom >> <thellstrom@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx> >>> Signed-off-by: Thomas Hellstrom <thellstrom@xxxxxxxxxx> >> 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