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
Description of problem:
I have noticed that my cursor get redrawn generating cursor image
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
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):
Steps to Reproduce:
1. a scrolling gnome-terminal
2. another application like firefox at the same coordinates but in
another virtual desktop
Actual Results: watch the cursor flicker on firefox if the cursor
within the range of the gnome terminal on the other virtual console
Expected Results: no cursor redraws
Using xorg-x11 6.8.1-12, gnome-terminal-2.7.3-1, and
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
> 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
What's going on here is that this code from damageCopyArea() in
if ((pSrc == pDst) && pSrc->pScreen->SourceValidate)
(*pSrc->pScreen->SourceValidate) (pSrc, srcx, srcy, width,
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 :-)