Bug 4633

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.