Bug 144022

Summary: Strange cursor redraws
Product: [Fedora] Fedora Reporter: Daniel Veillard <veillard>
Component: xorg-x11Assignee: Søren Sandmann Pedersen <sandmann>
Status: CLOSED NEXTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: gajownik, kem
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-16 22:57:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 136450, 136451    

Description Daniel Veillard 2005-01-03 20:57:08 UTC
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)

Comment 1 Daniel Veillard 2005-01-03 20:59:16 UTC
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.)


Comment 2 Mike A. Harris 2005-02-01 01:35:57 UTC
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.


Comment 4 Mike A. Harris 2005-02-01 01:44:42 UTC
Setting status to "NEEDINFO" for upstream bug report ID for
tracking, and adding FC4Target.

Comment 5 Daniel Veillard 2005-02-04 16:56:31 UTC
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

Comment 7 Søren Sandmann Pedersen 2005-03-10 19:21:42 UTC
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.


Comment 8 Daniel Veillard 2005-03-10 23:06:47 UTC
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

Comment 9 Daniel Veillard 2005-03-16 23:30:03 UTC
cool :-)