This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 144022 - Strange cursor redraws
Strange cursor redraws
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Søren Sandmann Pedersen
David Lawrence
: Triaged
Depends On:
Blocks: FC4Blocker FC4Target
  Show dependency treegraph
 
Reported: 2005-01-03 15:57 EST by Daniel Veillard
Modified: 2014-06-18 05:07 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-16 17:57:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Daniel Veillard 2005-01-03 15:57:08 EST
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 15:59:16 EST
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-01-31 20:35:57 EST
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-01-31 20:44:42 EST
Setting status to "NEEDINFO" for upstream bug report ID for
tracking, and adding FC4Target.
Comment 5 Daniel Veillard 2005-02-04 11:56:31 EST
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 14:21:42 EST
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 18:06:47 EST
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 18:30:03 EST
cool :-)

Note You need to log in before you can comment on or make changes to this bug.