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.
>
> > The other problem seems to be that X is racy with updating cursors (since
> > it does a setPos and setCursor separately, despite that this ioctl can do
> > it in one go) and so if you move the hotspot you get a jumpy cursor.
> > Radeon tried to paper over that but fundamentally you need to fix X and
> > use atomic (or at least universal plane cursor support) to fix this.
> >
> > Given all that I'm leaning towards "the future is atomic", let's please
> > not add hacks to legacy code. Aside: Atomic doesn't have the hotspot-x/y
> > properties yet, but really the only reason was that we don't yet have an
> > atomic driver needing them. Adding those props will be a tiny patch of a
> > few lines.
>
> Sinclair has started working on atomic support for vmwgfx, but we really
> need to fix this also in
> the legacy code, ugly or not.
I was thinking maybe it would be cleaner to not reset the hotspot to
0,0 in drm_mode_cursor_ioctl() and instead keep what was previously
configured, and only do the reset to 0,0 in lastclose (or some other
suitable place)? But I suppose that could break something else that
assume that drm_mode_cursor_ioctl() will do the reset.
>
> Thanks,
> Thomas
>
>
> >
> > Cheers, Daniel
> >> ---
> >> drivers/gpu/drm/drm_crtc.c | 10 ++++++----
> >> 1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> >> index 24c5434..93f80a5 100644
> >> --- a/drivers/gpu/drm/drm_crtc.c
> >> +++ b/drivers/gpu/drm/drm_crtc.c
> >> @@ -2874,7 +2874,8 @@ static int drm_mode_cursor_universal(struct drm_crtc *crtc,
> >>
> >> static int drm_mode_cursor_common(struct drm_device *dev,
> >> struct drm_mode_cursor2 *req,
> >> - struct drm_file *file_priv)
> >> + struct drm_file *file_priv,
> >> + bool from_2)
> >> {
> >> struct drm_crtc *crtc;
> >> int ret = 0;
> >> @@ -2907,7 +2908,8 @@ static int drm_mode_cursor_common(struct drm_device *dev,
> >> goto out;
> >> }
> >> /* Turns off the cursor if handle is 0 */
> >> - if (crtc->funcs->cursor_set2)
> >> + if (crtc->funcs->cursor_set2 &&
> >> + (from_2 || !crtc->funcs->cursor_set))
> >> ret = crtc->funcs->cursor_set2(crtc, file_priv, req->handle,
> >> req->width, req->height, req->hot_x, req->hot_y);
> >> else
> >> @@ -2953,7 +2955,7 @@ int drm_mode_cursor_ioctl(struct drm_device *dev,
> >> memcpy(&new_req, req, sizeof(struct drm_mode_cursor));
> >> new_req.hot_x = new_req.hot_y = 0;
> >>
> >> - return drm_mode_cursor_common(dev, &new_req, file_priv);
> >> + return drm_mode_cursor_common(dev, &new_req, file_priv, false);
> >> }
> >>
> >> /**
> >> @@ -2976,7 +2978,7 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
> >> {
> >> struct drm_mode_cursor2 *req = data;
> >>
> >> - return drm_mode_cursor_common(dev, req, file_priv);
> >> + return drm_mode_cursor_common(dev, req, file_priv, true);
> >> }
> >>
> >> /**
> >> --
> >> 2.4.3
> >>
> >> _______________________________________________
> >> dri-devel mailing list
> >> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel&d=BQIBAg&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=LvaoWKneZBMqoqvonmNbtrQ9sY1dL5unCG_D2_Xb--Y&s=IpenYkOeOFSMkCBvMp1_TEam7-KdFX4zbfCC943GC3M&e=
>
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
