On 02/24/2017 08:13 AM, Daniel Vetter wrote: > On Fri, Feb 24, 2017 at 7:44 AM, Thomas Hellstrom <thellst...@vmware.com> > wrote: >> On 02/22/2017 08:04 PM, Daniel Vetter wrote: >>> On Tue, Feb 21, 2017 at 11:42 AM, Thomas Hellstrom >>> <thellst...@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: <sta...@vger.kernel.org> >>>> Signed-off-by: Thomas Hellstrom <thellst...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
