radeon_cursor

[Michel Dänzer]

On Tue, 2005-01-11 at 01:46 -0500, Vladimir Dergachev wrote:
> 
> On Tue, 11 Jan 2005, Michel [ISO-8859-1] Dnzer wrote:
> 
> > On Sun, 2005-01-02 at 15:19 -0500, Vladimir Dergachev wrote:
> >>
> >>   My understanding is that the cursor update runs in a separate thread (as
> >> the mouse still works when the server is otherwise locked up).
> >
> > I've been fooled by this before as well, but no. Only mouse movement is
> > handled asynchronously.
> 
> Do I understand it right that the code invoked by a signal writes cursor 
> position registers only ?

Yes.


> >>   This is indeed what I see with R300 - when glxtest is running full speed
> >> I get a lockup when mouse crosses window boundaries (this involves
> >> changing cursor shape because of window manager).
> >
> > Have you verified that this doesn't happen with SW cursor as well?
> 
> No, I have not. Most of the lockups went away after I put a sequence to do 
> some sort of cache flush (not sure what exactly as it is just a guess).
> 
> However, I do find that often when I make a mistake (like supplying wrong 
> texture offset) then the engine locks up on mouse move.
> 
> Perhaps, the problem has been merely masked..

Possibly. It would certainly make sense to idle the engine before
uploading the cursor data, or even better use the new HostDataBlit
functions to do it.


-- 
Earthling Michel Dänzer      |     Debian (powerpc), X and DRI developer
Libre software enthusiast    |   http://svcs.affero.net/rm.php?r=daenzer