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.
Created attachment 3425 [details] xorg.conf
Changing component field as this is more likely specific to the driver than to EXA. Does this also happen without MergedFB?
Huh? MergedFB isn't used. This is single head.
Please attach the log file then.
Created attachment 3736 [details] Xorg.log
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.
(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 problem? How about Option "ColorTiling" "off"?
ColorTiling had no effect. I'm building a new X right now so we'll see what effect that has in a bit.
Now running new X server and HW cursor works. Unfortunately the cursor bug is still present.
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?
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.
Can you please attach a new log file, taken after the cursor is fine again after the login?
Created attachment 3754 [details] Xorg.log 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.
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()?
Any convenient way of doing this? Or do I have to gdb the entire thing and put in breakpoints?
Can't think of a more convenient way unfortunately.
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 ()
I'm working on this.
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.
Created attachment 4105 [details] [review] Proposed fix Unless there are objections, I'll commit this shortly after the 6.9/7.0 release.
Committed.
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.