Mailinglist Archive: radeonhd (427 mails)

[Yang Zhao <yang@xxxxxxxxxx>]

2009/5/4 Matthias Hopf <mhopf@xxxxxxx>:
> 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".

AFAICS it's just a logical result of RandR's cursor behaviour and us
requiring both cursors to always be enabled. Moving from one CRTC to
the other while passing through an invalid virtual area (due to
mismatched display dimensions) results in the calls:

  setPosition(crtc1, <somewhere on screen>) => disable(crtc1) =>
setPosition(crtc2, <new position>) => enable(crtc2)



> > 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.

In that case, I can work this back into rhdCrtcSetPosition().
displayCursor() is way too overloaded right now, and I would like to
get rid of it entirely.

It would be nice to get a confirmation if this is still required with
the reworked code.

-- 
Yang Zhao
http://yangman.ca
--
To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx