On May 04, 09 09:24:05 -0700, Yang Zhao wrote:
@@ -636,11 +644,26 @@ rhdCrtcShowCursor(struct rhdCrtc *Crtc) [...] + /* Move cursor off-screen so it won't be visible*/ + RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_POSITION, + (Crtc->X + Crtc->Width) << 16 | (Crtc->Y + Crtc->Height)); + RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_HOT_SPOT, 0); +
Is this consistent with the solution Alex found for how to fix part of the corruptions (never move outside Crtc boundaries + don't let end at multiples of 128)? One way to circumvent this would be to use (0, Crtc->Y+Crtc->Height) as coordinates. What do you think?
This is to work around a corner case where the cursors would get enabled while the cursor coordinates for the "inactive" CRTC is still in the visible area, leaving a ghost pointer. Last I checked, it's
Yes, I have seen that. Side effect by my last "fix".
worked around in radeon by setting the cursor dimension to 1x1.
Ah. I see. This is still one pixel wrong ;) I like moving the cursor outside the visible screen better.
In any case, the multiples-of-128 and don't-be-outside logic wasn't included. Lets use 0 for X if it may be an issue.
0 should be safe. I don't think coordinates outside the screen with a higher y are of any issue, the logic in the Alex' patch for the issue he found in-house only addressed X as well.
rhdCrtcSetCursorPosition(struct rhdCrtc *Crtc, int x, int y) [...] - displayCursor(Crtc, TRUE); + RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_POSITION, x << 16 | y); + RHDRegWrite(Cursor, Cursor->RegOffset + D1CUR_HOT_SPOT, hotx << 16 | hoty);
This doesn't change cursor width any more if necessary (see above). That has been the reason for the change to use displayCursor everywhere. It does fix the cursor corruption issues (while it introduced other issues ;) on a machine here, so I'm positive that this is actually necessary.
What issues are caused by cursor going beyond the CRTC area? I wasn't
I don't know, but this was included and commented on in the same commit
that fixed the end-on-multiple-of-128 patch. On some cards the cursor is
garbled more or less if you hit a multiple of 128 with the right edge of
the cursor - and keeps this for the neighboring pixels, even if the
cursor is moved again.
We have a system here that exhibits this bug. It only happens after
quite some running time, so it's probably a speed path in the cache
design.
Matthias
--
Matthias Hopf