Bug 29433 - Mouse cursor stutter with kernel 2.6.35
Summary: Mouse cursor stutter with kernel 2.6.35
Status: RESOLVED DUPLICATE of bug 29536
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2010-08-07 01:48 UTC by Mjules
Modified: 2010-08-12 15:08 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

dmesg (43.07 KB, text/plain)
2010-08-09 09:27 UTC, Mjules
no flags Details
xorg.log (39.79 KB, text/plain)
2010-08-09 09:27 UTC, Mjules
no flags Details

Description Mjules 2010-08-07 01:48:17 UTC

since I upgraded to kernel 2.6.35, my mouse cursor is not fluid anymore. When I move it, it stutters sometimes (that is, it makes a small jump on the screen). 

According to latencytop, it seems to come from drm_mod_cursor ioctl which takes as much as 100ms when the cursor jump. I attach a screenshot of latencytop window.
This issue seems to appears randomly, maybe more frequent when the cursor change (arrow to select hand etc.) but I'm not sure.

I don't have this problem with 2.6.34 (nor and ). 
I'm using vanilla kernel (packaged by my distro but without any third party patch) :
Linux tue-amour 2.6.35-1mdv #1 SMP Mon Aug 2 05:50:00 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

Xorg 1.7.7
radeon driver 6.13.1 with KMS 
mesa 7.8.1
libdrm 2.4.21

radeon 4870, only one screen attached.
01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4870]
Comment 1 Alex Deucher 2010-08-09 08:46:16 UTC
Can you bisect to see what commit caused this?  There haven't been any changes to the cursor code in quite a while.
Comment 2 Alex Deucher 2010-08-09 08:53:42 UTC
Is the desktop locked up when this happens (i.e., can you still interact with apps)?  Please attach your xorg log and dmesg.
Comment 3 Mjules 2010-08-09 09:22:12 UTC
thanks for taking care :)

desktop is not frozen nor locked when it happens.
It's just that when I move the cursor, sometimes it « jumps » to about 1cm forward on the screen (for an analogy it's the same sensation when a video drop frame).

I'll attach dmesg and Xorg.log but I didn't manage to spot anything in there.
Comment 4 Mjules 2010-08-09 09:27:05 UTC
Created attachment 37730 [details]
Comment 5 Mjules 2010-08-09 09:27:36 UTC
Created attachment 37731 [details]
Comment 6 Mjules 2010-08-09 12:49:31 UTC
My bisection point to commit :

eb1f8e4f3be898df808e2dfc131099f5831d491d is the first bad commit
commit eb1f8e4f3be898df808e2dfc131099f5831d491d
Author: Dave Airlie <airlied@redhat.com>
Date:   Fri May 7 06:42:51 2010 +0000

    drm/fbdev: rework output polling to be back in the core. (v4)
    After thinking it over a lot it made more sense for the core to deal with
    the output polling especially so it can notify X.
    v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings.
    v3: add config lock take inside polling, add intel/nouveau poll init/fini calls
    v4: config lock was a bit agressive, only needed around connector list reading.
    otherwise it could re-enter.
    glisse: discard drm_helper_hpd_irq_event
    v3: Reviewed-by: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Dave Airlie <airlied@redhat.com>

:040000 040000 01a1bf1ae4e06bfd3ae9ae67b5b5059e964f5ae4 041231a5c060e531ce0d8127c6f7abc79c14ce76 M	drivers
:040000 040000 b67fd6698fa239d26ca9fa2296ea2403e1eaaf1c cadb905c6d8647313107790ce8b681f4611ee726 M	include
Comment 7 Nicolas Kaiser 2010-08-09 14:48:42 UTC
I could imagine that the latency is caused by the VGA port getting polled.

Can you connect the monitor to VGA instead of DVI? This might work around the problem.
Comment 8 Mjules 2010-08-11 09:24:59 UTC
(In reply to comment #7)
> I could imagine that the latency is caused by the VGA port getting polled.
> Can you connect the monitor to VGA instead of DVI? This might work around the
> problem.

When the monitor is connected to VGA, symptoms disappear and according to latencytop, drm_mode_cursor_ioctl only takes a maximum of 5ms.

When both output (VGA + DVI) are connected (clone mode, on the same monitor), symptoms reappears (latency around 100ms).
Comment 9 Alex Deucher 2010-08-12 15:08:39 UTC

*** This bug has been marked as a duplicate of bug 29536 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.