GNOME Bugzilla – Bug 752616
wayland: Always apply scaling factor to cursor hotspot and dimension
Last modified: 2015-07-20 10:13:16 UTC
Prior to this patch, the hotspot would be passed in buffer coordinate space. Where this were ever tested, i.e. in a patched mutter, the server interpreted them incorrectly, which meant it went undiscovered. In the updated mutter patches the incorrect behavior in GTK+ was discovered due to the behavior in mutter was corrected. In the themed cursor case, the dimensions were not correctly scaled either, but this had no negative visible effect because the dimension is only used for reporting damage tracking, and passing a bigger damage region than surface has no negative visible effects.
Created attachment 307735 [details] [review] wayland: Always apply scaling factor to cursor hotspot and dimension
Review of attachment 307735 [details] [review]: LGTM. /me wonders if it's really needed to store scale separately for surface/non-surface cases after reading code around.
Attachment 307735 [details] pushed as 2943bfe - wayland: Always apply scaling factor to cursor hotspot and dimension
(In reply to Carlos Garnacho from comment #2) > Review of attachment 307735 [details] [review] [review]: > > LGTM. /me wonders if it's really needed to store scale separately for > surface/non-surface cases after reading code around. Reason is mostly to have a logical separation between the "surface based" cursor state, and a "wl_cursor" based cursor state. Only one is valid at any time, so a "scale" parameter could be shared, but it'd mix the what parts is valid at what time separation.
(In reply to Jonas Ådahl from comment #4) > (In reply to Carlos Garnacho from comment #2) > > Review of attachment 307735 [details] [review] [review] [review]: > > > > LGTM. /me wonders if it's really needed to store scale separately for > > surface/non-surface cases after reading code around. > > Reason is mostly to have a logical separation between the "surface based" > cursor state, and a "wl_cursor" based cursor state. Only one is valid at any > time, so a "scale" parameter could be shared, but it'd mix the what parts is > valid at what time separation. That was partly my point, cursors are meant to be static after creation, the cursor-type property is construct only, so you're not going to get changes between wl_cursor and surface backing.