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

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

[Michael Zoran]

Commonly used desktop environments such as xfce4 and gnome
on debian sid can flood the graphics drivers with cursor
updates.  Because the current implementation is waiting
for a vblank between cursor updates, this will cause the
display to hang for a long time since a typical refresh
rate is only 60Hz.

This is unnecessary and unexpected by user mode software,
so simply swap out the cursor frame buffer without waiting.

Signed-off-by: Michael Zoran <mzoran-O+n0w2l5AFbk1uMJSBkQmQ@public.gmane.org>
---
 drivers/gpu/drm/vc4/vc4_plane.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index f7a229df572d..110224c3a3ac 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -20,6 +20,7 @@
 
 #include "vc4_drv.h"
 #include "vc4_regs.h"
+#include "drm_atomic.h"
 #include "drm_atomic_helper.h"
 #include "drm_fb_cma_helper.h"
 #include "drm_plane_helper.h"
@@ -769,12 +770,6 @@ vc4_update_plane(struct drm_plane *plane,
 	if (!plane_state)
 		goto out;
 
-	/* If we're changing the cursor contents, do that in the
-	 * normal vblank-synced atomic path.
-	 */
-	if (fb != plane_state->fb)
-		goto out;
-
 	/* No configuring new scaling in the fast path. */
 	if (crtc_w != plane_state->crtc_w ||
 	    crtc_h != plane_state->crtc_h ||
@@ -783,6 +778,11 @@ vc4_update_plane(struct drm_plane *plane,
 		goto out;
 	}
 
+	if (fb != plane_state->fb) {
+		drm_atomic_set_fb_for_plane(plane->state, fb);
+		vc4_plane_async_set_fb(plane, fb);
+	}
+
 	/* Set the cursor's position on the screen.  This is the
 	 * expected change from the drm_mode_cursor_universal()
 	 * helper.
-- 
2.11.0

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

[Michel Dänzer]

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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Michael Zoran]

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






_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

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

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 588 bytes --]

Michael Zoran <mzoran@crowfest.net> writes:

> Commonly used desktop environments such as xfce4 and gnome
> on debian sid can flood the graphics drivers with cursor
> updates.  Because the current implementation is waiting
> for a vblank between cursor updates, this will cause the
> display to hang for a long time since a typical refresh
> rate is only 60Hz.
>
> This is unnecessary and unexpected by user mode software,
> so simply swap out the cursor frame buffer without waiting.
>
> Signed-off-by: Michael Zoran <mzoran@crowfest.net>

Reviewed and pushed to drm-misc-next.  Thanks!

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Michel Dänzer]

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 [...]".


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [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.



_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel

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

[Michel Dänzer]

On 01/03/17 11:00 AM, Michael Zoran wrote:
> 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.

A client asks the X server to use the spinning cursor, but the actual
animation and corresponding DRM_IOCTL_MODE_CURSOR(2) calls are performed
by the X server itself.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

_______________________________________________
linux-rpi-kernel mailing list
linux-rpi-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel