| Message ID | 20170224015431.24583-1-mzoran@crowfest.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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...
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!
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 [...]".
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.
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.
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.
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> --- drivers/gpu/drm/vc4/vc4_plane.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)