[PATCH] drm: vc4: Don't wait for vblank when updating the cursor

[Michael Zoran]

On Wed, 2017-03-01 at 10:48 +0900, Michel Dänzer wrote:
> On 01/03/17 12:45 AM, Michael Zoran wrote:
> > On Tue, 2017-02-28 at 16:42 +0900, Michel Dänzer wrote:
> > > On 24/02/17 10:54 AM, Michael Zoran wrote:
> > > > Commonly used desktop environments such as xfce4 and gnome
> > > > on debian sid can flood the graphics drivers with cursor
> > > > updates.
> > > 
> > > FWIW, this has nothing to do with the desktop environment or
> > > indeed
> > > the
> > > client side at all. Translating input to HW cursor movement is
> > > handled
> > > entirely inside the X server.
> > > 
> > > 
> > 
> > Yes, as your point out it may well be the x server that is causing
> > this.  I wasn't sure if it was the windows manager or the x server
> > that
> > was doing this.
> > 
> > Either way, when opening a new application the driver gets flooded
> > with
> > cursor updates as something is animating a spinning cursor.  Since
> > the
> > refresh rate is only 60Hz, I see a very long hang in the
> > desktop(several minutes) where nothing responds.  SSHing into the
> > RPI
> > still works though even though it appears hung.
> > 
> > I had a few people on the net test the changes and they all report
> > that
> > without the change xfce4 and gnome are both unusable on the
> > RPI.  With
> > the change, things work fine.  Not waiting for the vblank on cursor
> > updates is what other drivers appears to do as well...
> 
> Sure. My point is merely that the commit log should say "Xorg can
> flood
> [...]" instead of "Commonly used desktop environments such as xfce4
> and
> gnome on debian sid can flood [...]".
> 

Thanks for the tip.  I don't plan to submit many vc4 changes, but it's
good to know.

BTW, you wouldn't happen to know what component is animating the
spinning cursor?  I still highly suspect it's either the window
manager(xfwm or mutter) or possibly the application that's drawing the
taskbar.