On 11/29/2015 10:18 AM, Daniel Vetter wrote: > On Fri, Nov 27, 2015 at 01:24:11PM +0100, Thomas Hellstrom wrote: >> On 11/27/2015 01:02 PM, Ville Syrjälä wrote: >>> On Fri, Nov 27, 2015 at 12:42:15PM +0100, Thomas Hellstrom wrote: >>>> On 11/27/2015 11:11 AM, Daniel Vetter wrote: >>>>> On Thu, Nov 26, 2015 at 10:52:14AM -0800, Thomas Hellstrom wrote: >>>>>> If the drm_mode_cursor_ioctl is called and the cursor_set2 callback is >>>>>> implemented, the cursor hotspot is set to (0,0) which is incompatible >>>>>> with vmwgfx where the hotspot should instead remain unchanged. >>>>>> >>>>>> So if the driver implements both cursor_set2 and cursor_set, prefer calling >>>>>> the latter from the drm_mode_cursor ioctl. >>>>>> >>>>>> Signed-off-by: Thomas Hellstrom <thellstrom@xxxxxxxxxx> >>>>> That looks like papering over a bug in the client - it simply shouldn't >>>>> mix these two if it expects the hotspot to stick around. There was also >>>>> recently a big discussion about hotspot behaviour, and the conclusion was >>>>> that qxl got it all wrong. Since that was specifically added for qxl I'm >>>>> not sure how well this was ever tested ... >>>> No, this is not the case, This is for old Xorg userspace that first sets >>>> the hotspot using our ancient >>>> driver-private ioctl and then calls drm_mode_cursor() to update the cursor. >>>> >>>> Now if we were to implement cursor_set2, which is apparently needed to >>>> get gnome-shell/Wayland cursors in the right place, without this fix, it >>>> would break old Xorg, so we don't have much choice in this case from >>>> what I can tell. >>>> >>>> The root problem here is that the drm_mode_cursor() behaviour in the >>>> presence of cursor_set2 didn't take the existing vmware hotspot >>>> semantics into account. > Ugh. I think the simplest solution is to not mix up the two hotspots, i.e. > separately keep track of both the legacy vmwgfx hotspot and the drm core > hotspot. Then in the actual cursor set code add them. A bit of ugly in the > vmwgfx code (but not much), instead of leaking that driver private legacy > ioctl semantics into drm core. Would that work? > > Hmm. Yes it would probably work. Good idea. I guess we just need to make sure that both hotspots are reset to (0,0) at master drop. /Thomas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
