Bug 39989 - SD grabs interact badly with animated cursors
Summary: SD grabs interact badly with animated cursors
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Peter Hutterer
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-08-10 16:08 UTC by Tom Jaeger
Modified: 2013-02-07 23:56 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
client that performs a passive SD grab (1.54 KB, text/x-csrc)
2011-08-10 16:08 UTC, Tom Jaeger
no flags Details
hjudt's patch (1.50 KB, patch)
2011-08-10 16:09 UTC, Tom Jaeger
no flags Details | Splinter Review
0001-render-don-t-bother-with-animated-cursors-on-floatin.patch (857 bytes, patch)
2012-01-05 19:21 UTC, Peter Hutterer
no flags Details | Splinter Review
fix-grab-animated-cursor.patch (2.13 KB, patch)
2012-04-12 03:12 UTC, Harald Judt
no flags Details | Splinter Review

Description Tom Jaeger 2011-08-10 16:08:01 UTC
Created attachment 50107 [details]
client that performs a passive SD grab

Hi Peter,

This issue is related to the following old bug report that never got fully resolved.

https://bugs.freedesktop.org/show_bug.cgi?id=19034

What happens (I think) is that under certain circumstances the SD ends up with an animated cursor that repeatedly replaces the MD cursor.

Steps to reproduce:
1. Start the busycursor program (https://bugs.freedesktop.org/show_bug.cgi?id=23034)
2. Execute grab <device-number>, where <device-number> belongs to a pointer device.
3. Use the device to click anywhere inside the busycursor window, grab should exit
4. Move the pointer to another window, notice how the animated cursor from the busycursor window has taken over the desktop.  The correct cursor may be visible for a short time before it gets overwritten by the animated cursor.

Comment 11 in the old bug report has a (hackish?) patch that fixed the issue, hjudt [1] was kind enough to port it to current git and confirms that it still works.  I'm not quite sure what the right approach to fixing this problem would be, since I've forgotten most of the details.

Thanks,
Tom

[1] https://sourceforge.net/apps/trac/easystroke/ticket/96
Comment 1 Tom Jaeger 2011-08-10 16:09:05 UTC
Created attachment 50108 [details] [review]
hjudt's patch
Comment 2 Harald Judt 2012-01-05 00:53:25 UTC
This bug is still present in current GIT, and the patch still applies and fixes the problem with no ill side-effects observed.
Comment 3 Peter Hutterer 2012-01-05 19:21:02 UTC
Created attachment 55197 [details] [review]
0001-render-don-t-bother-with-animated-cursors-on-floatin.patch

This part alone seems to fix the issue for me, can you please confirm that?
Comment 4 Harald Judt 2012-01-06 02:44:33 UTC
Indeed, i confirm this much simpler patch fixes the problem too.
Comment 5 Peter Hutterer 2012-01-15 16:56:48 UTC
commit bbb6b8c834e0e1491ca14403b5d0840dd14380d3
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Jan 6 13:20:45 2012 +1000

    render: don't bother with animated cursors on floating slaves (#39989)
Comment 6 Jeremy Huddleston Sequoia 2012-01-18 10:59:12 UTC
This is also on server-1.11-branch
Comment 7 Harald Judt 2012-02-21 09:49:22 UTC
I'm sorry, but I have to reopen this bug. I thought the patch that has been committed has fixed the issue, but it still happens, though very rarely now.

Unfortunately, I cannot reproduce it using the known steps and don't know what to do to make it happen. Yet, there it is and so some part still needs fixing.

Would applying the complete patch from comment #1 (attachment 50108 [details] [review]) instead of the simple fix break something? Until now, I did not notice any problems using that patch.
Comment 8 Peter Hutterer 2012-02-22 17:08:33 UTC
(In reply to comment #7)
> I'm sorry, but I have to reopen this bug. I thought the patch that has been
> committed has fixed the issue, but it still happens, though very rarely now.

note that the patch caused regressions and has been reverted upstream and in 1.11. so depending on what version you're running, you may not have the patch.

> Would applying the complete patch from comment #1 (attachment 50108 [details] [review] [review]) instead of
> the simple fix break something? Until now, I did not notice any problems using
> that patch.

You most likely need 
http://patchwork.freedesktop.org/patch/9166/
Comment 9 Peter Hutterer 2012-02-22 17:09:19 UTC
(In reply to comment #8)
> note that the patch caused regressions and has been reverted upstream and in
> 1.11. so depending on what version you're running, you may not have the patch.

cancel this statement, confused it with another bug.
Comment 10 Harald Judt 2012-02-23 04:49:57 UTC
Ok, thanks. I will try the patch at the bottom of the page you mentioned and see if it helps. Testing this will take some time though, as the problem is not easy to reproduce.
Comment 11 Harald Judt 2012-04-12 03:12:21 UTC
Created attachment 59844 [details] [review]
fix-grab-animated-cursor.patch

Now that the patchset is in git, I gave it another try. Unfortunately, things did not get better and I can still reproduce the bug. It *might* be that it occurs only after resuming from standby/hibernation, but I'm not sure about that.

Anyway, since I need it, I've modified the original version of my previous patch so that it applies on current git.
Comment 12 Harald Judt 2013-02-07 19:17:34 UTC
I have forgotten to apply this patch to recent xserver releases, but the issue does not happen anymore, so I believe it is finally fixed (tested with xorg-server-1.13.2).
Comment 13 Peter Hutterer 2013-02-07 23:56:09 UTC
sorry, forgot to close this bug. Fixed with

commit bbb6b8c834e0e1491ca14403b5d0840dd14380d3
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Fri Jan 6 13:20:45 2012 +1000

    render: don't bother with animated cursors on floating slaves (#39989)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.