Red Hat Bugzilla – Bug 144022
Strange cursor redraws
Last modified: 2014-06-18 05:07:36 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041020 Firefox/0.10.1 Description of problem: I have noticed that my cursor get redrawn generating cursor image flicker even if I don't move the mouse or the underlying image doesn't change. It didn't depend on the application having the focus, or over which the cursor was drawn, but was depending on the cursor location on the screen. After a bit of checking it appears to be related to virtual screen, if the cursor is positionned at the x/y coordinate of a gnome-terminal whose content is scrolling but not displayed due to being on another virtual screen, then the cursor is redrawn as the terminal image is updated. Moving the cursor coordinate outside of the terminal area stops the flicker. Version-Release number of selected component (if applicable): xorg-x11-6.8.1-12 How reproducible: Always Steps to Reproduce: 1. a scrolling gnome-terminal 2. another application like firefox at the same coordinates but in another virtual desktop 3. Actual Results: watch the cursor flicker on firefox if the cursor coordinates are within the range of the gnome terminal on the other virtual console Expected Results: no cursor redraws Additional info: Using xorg-x11 6.8.1-12, gnome-terminal-2.7.3-1, and metacity-2.8.6-2.1, It is actually a RHEL4 beta desktop, but very close to FC3. hardware is Matrox 450 dual head running in xinerama mode. Excerps from /var/log/Xorg.0.log: (--) PCI:*(1:0:0) Matrox Graphics, Inc. MGA G400 AGP rev 130,... (--) Chipset mgag400 found (**) MGA(0): Depth 16, (--) framebuffer bpp 16 (==) MGA(0): RGB weight 565 (II) MGA(0): Using XFree86 Acceleration Architecture (XAA)
Feedback from owen on the question: > Well, if your description is accurate, that would be an X server bug. It > sort of sounds like something is not checking whether a window is > visible > before hiding the software cursor when drawing on that window. > > (I don't think the MGA handles alpha cursors, so the bluecurve cursor > theme will give you a software cursor.)
Please report this issue in the X.org bug tracker at http://bugs.freedesktop.org in the "xorg" component. This might be a bug in the DAMAGE code, or could be a driver bug perhaps. Please paste the upstream bug URL here, and we'll track it upstream.
Setting status to "NEEDINFO" for upstream bug report ID for tracking, and adding FC4Target.
I don't have a login in X.org bug tracker. I think this will stay as "NEEDINFO". Close if you don't expect to propagate the bug report. Daniel
What's going on here is that this code from damageCopyArea() in miext/damage/damage.c: if ((pSrc == pDst) && pSrc->pScreen->SourceValidate) (*pSrc->pScreen->SourceValidate) (pSrc, srcx, srcy, width, height); validates the source, even when the source is not visible. Thus turns off the cursor even though the CopyArea is not actually going to do anything, producing the flicker. The immediate fix, and the one we should put in FC4 is to only validate if the source area is actually visible. A more general fix would be to double buffer the software cursor so that it won't flicker even when the source area actually is visible. This may not be worth it though as modern hardware is probably able to do argb cursors.
I can't comment on the solution but I can just tell I'm still seing this behaviour with xorg-x11-6.8.1-23.EL :-) Daniel
cool :-)