After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695512 - wayland backend ignores cursor hotspot
wayland backend ignores cursor hotspot
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: wayland
 
 
Reported: 2013-03-09 17:28 UTC by Matthias Clasen
Modified: 2013-03-21 16:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wayland: Keep hotspot when changing cursors (1.71 KB, patch)
2013-03-21 01:50 UTC, Matthias Clasen
committed Details | Review
fix for the real problem (2.88 KB, patch)
2013-03-21 03:06 UTC, Kristian Høgsberg
none Details | Review

Description Matthias Clasen 2013-03-09 17:28:47 UTC
This can be seen clearly when trying the resize grip in the csd branch. Move toward it with an arrow cursor. As soon as the tip of the arrow enters the triangle, the arrow gets replaced with a sw-resize cursor. And the hotspots are not lined up at all
Comment 1 Matthias Clasen 2013-03-09 17:29:29 UTC
Interestingly, this corrects itself when I click - the cursor jumps to put the hotspot where I clicked.
Comment 2 Matthias Clasen 2013-03-21 01:50:21 UTC
Created attachment 239431 [details] [review]
wayland: Keep hotspot when changing cursors

We need to pass the delta between the old and new hotspot
when attaching the new cursor surface, to keep the hotspot
at the same position. We can't deal with this in the compositor,
since the set_cursor call already overwrites the old hotspot,
so the information is lost by the time the attach happens.
Unfortunately, we can't query the initial hotspot from
the compositor, so the first cursor change will make the
hotspot jump.
Comment 3 Matthias Clasen 2013-03-21 02:21:06 UTC
Attachment 239431 [details] pushed as 26d3fc3 - wayland: Keep hotspot when changing cursors
Comment 4 Kristian Høgsberg 2013-03-21 03:06:34 UTC
Created attachment 239438 [details] [review]
fix for the real problem

From 0d9d808217a04ee965ce5f60f9aff00b2ec4938e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Kristian=20H=C3=B8gsberg?= <krh@bitplanet.net>
Date: Wed, 20 Mar 2013 22:02:42 -0400
Subject: [PATCH] wayland: Use the pointer enter serial when setting cursor
 surface

wl_pointer.set_cursor is rejected if the serial number doesn't match
the enter serial number for the wl_pointer.  We passed the right serial
number when setting the cursor surface in response to the enter event.
Later set_cursor requests fail, but we can still attach new buffers to
our cursor surface, which is why the cursor changed, but the hotspot
didn't update.  Clicking in the decoration results in a leave/enter pair
which triggers wl_pointer.set_cursor with the right serial. That's why
clicking the decoration sets the right cursor.
Comment 5 Matthias Clasen 2013-03-21 04:26:55 UTC
<mclasen> krh: cursor changes are not quite right with your fix
<mclasen> it appears sticky, sometimes
<mclasen> e.g click on the titlebar, and let go
<mclasen> the hand sticks around until you move over the content or window frame
<mclasen> also, when entering the window slowly from the outside, I don't get the resize cursor that I get when leaving the window slowly...
Comment 6 Kristian Høgsberg 2013-03-21 12:56:59 UTC
commit a80998127ce779b156df50e8d1ebaa4eedab31b5
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Thu Mar 21 08:51:35 2013 -0400

    wayland: Clear current cusor on leave so we always set it on enter
    
    Commit 0d9d808217a04ee965ce5f60f9aff00b2ec4938e fixed the hotspot issue,
    but commit f2cc52fddd74b3064eec85e17161ebbc4ee14f49 then optimized away
    cursor changes a little too aggressively.  We always need to set the
    cursor on enter.  Make sure we clear the current cursor on leave so we
    don't think it's already set on the next enter.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=695512