Bug 4633 - Initial mouse pointer incorrect with EXA
Summary: Initial mouse pointer incorrect with EXA
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/Radeon (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Michel Dänzer
QA Contact:
Depends on:
Blocks: 5041
  Show dependency treegraph
Reported: 2005-09-29 00:59 UTC by Pierre Ossman
Modified: 2006-01-23 13:57 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

xorg.conf (3.99 KB, text/plain)
2005-09-29 01:00 UTC, Pierre Ossman
no flags Details
Xorg.log (37.63 KB, text/plain)
2005-11-08 07:22 UTC, Pierre Ossman
no flags Details
Xorg.log (37.66 KB, text/plain)
2005-11-09 07:54 UTC, Pierre Ossman
no flags Details
Proposed fix (6.68 KB, patch)
2005-12-16 19:52 UTC, Michel Dänzer
no flags Details | Splinter Review

Description Pierre Ossman 2005-09-29 00:59:52 UTC
When EXA acceleration is turned on the initial mouse pointer (the X) is just a
big , semi-transparent square.

The color seems to be taken from the GNOME splash screen since it changes if the
splash screen is replaced by another image. It is a single color across the
entire square though, even when the splash image contains no uniform areas.

CVS snapshot is from 2005-09-28, card is a Radeon Mobility 9200.
Comment 1 Pierre Ossman 2005-09-29 01:00:20 UTC
Created attachment 3425 [details]
Comment 2 Michel Dänzer 2005-11-08 06:22:19 UTC
Changing component field as this is more likely specific to the driver than to EXA.

Does this also happen without MergedFB?
Comment 3 Pierre Ossman 2005-11-08 06:51:18 UTC
Huh? MergedFB isn't used. This is single head.
Comment 4 Michel Dänzer 2005-11-08 07:14:35 UTC
Please attach the log file then.
Comment 5 Pierre Ossman 2005-11-08 07:22:12 UTC
Created attachment 3736 [details]
Comment 6 Pierre Ossman 2005-11-08 07:24:56 UTC
I can also point out that X seems to switch to software cursor (flickering with
screen updates). Perhaps this happens the pointer starts to be correctly
rendered. Unable to test it at that point.
Comment 7 Michel Dänzer 2005-11-08 07:50:43 UTC
(In reply to comment #6)
> I can also point out that X seems to switch to software cursor (flickering with
> screen updates).

This should fixed in CVS, see bug 4951. Does that fix have any impact on this

How about Option "ColorTiling" "off"?
Comment 8 Pierre Ossman 2005-11-08 08:26:31 UTC
ColorTiling had no effect. I'm building a new X right now so we'll see what
effect that has in a bit.
Comment 9 Pierre Ossman 2005-11-08 09:08:33 UTC
Now running new X server and HW cursor works. Unfortunately the cursor bug is
still present.
Comment 10 Michel Dänzer 2005-11-09 00:57:43 UTC
Bummer. Is it still only broken initially though, or all the time now? If the
former, when exactly does it go from broken to correct?
Comment 11 Pierre Ossman 2005-11-09 01:09:35 UTC
It is ok when starting GDM. It then goes bad when logging in (which uses the
same X server right?) and goes ok again somewhere during the gnome start up.

It's difficult to tell excactly where since the startup text goes by rather quickly.
Comment 12 Michel Dänzer 2005-11-09 02:56:06 UTC
Can you please attach a new log file, taken after the cursor is fine again after
the login?
Comment 13 Pierre Ossman 2005-11-09 07:54:56 UTC
Created attachment 3754 [details]

Not sure what you mean but here is a log from the current X server.

Everything up to "ProcXCloseDevice" is when gdm is running the show. After that
is when I log on.

The "ProcXCloseDevice", and following lines, show up around the time the
pointer gets "fixed". So no output when it goes wrong.
Comment 14 Michel Dänzer 2005-11-10 06:48:37 UTC
Okay, so the problem seems to be that the offscreen area for the HW cursor is
freed, but I'm not sure why that would happen. Can you try to get call traces
for RADEONCursorSave()?
Comment 15 Pierre Ossman 2005-11-10 07:01:31 UTC
Any convenient way of doing this? Or do I have to gdb the entire thing and put
in breakpoints?
Comment 16 Michel Dänzer 2005-11-10 07:16:15 UTC
Can't think of a more convenient way unfortunately.
Comment 17 Pierre Ossman 2005-11-10 07:36:34 UTC
That was a lot less painful than I expected. RADEONCursorSave() was only called
once, and it was right before the cursor went bad.

#0  0xb7c74e1f in RADEONCursorSave ()
   from /usr/X11R6/lib/modules/drivers/radeon_drv.so
#1  0xb7ad0f73 in ExaOffscreenKickOut () from /usr/X11R6/lib/modules/libexa.so
#2  0xb7ad0fd1 in ExaOffscreenSwapOut () from /usr/X11R6/lib/modules/libexa.so
#3  0xb7ad106d in exaEnableDisableFBAccess ()
   from /usr/X11R6/lib/modules/libexa.so
#4  0x08092d78 in xf86RandRSetMode ()
#5  0x08092fd7 in xf86RandRSetConfig ()
#6  0x0815ed5b in ProcRRSetScreenConfig ()
#7  0x080c0ac2 in Dispatch ()
#8  0x080cc233 in main ()
Comment 18 Michel Dänzer 2005-11-15 02:40:47 UTC
I'm working on this.
Comment 19 Michel Dänzer 2005-12-06 04:22:22 UTC
As EXA is still considered experimental in 6.9/7.0, I'm afraid the fix for this
is too invasive to put in at this point. I'll commit it soon after the tree
re-opens for development after the releases.
Comment 20 Michel Dänzer 2005-12-16 19:52:39 UTC
Created attachment 4105 [details] [review]
Proposed fix

Unless there are objections, I'll commit this shortly after the 6.9/7.0
Comment 21 Alan Hourihane 2006-01-24 08:57:35 UTC

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.