https://bugs.freedesktop.org/show_bug.cgi?id=29433
Summary: Mouse cursor stutter with kernel 2.6.35 Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: mjulien.m@gmail.com
Hi,
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 2.6.34.1 and 2.6.34.2 ). 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]
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #1 from Alex Deucher agd5f@yahoo.com 2010-08-09 08:46:16 PDT --- Can you bisect to see what commit caused this? There haven't been any changes to the cursor code in quite a while.
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #2 from Alex Deucher agd5f@yahoo.com 2010-08-09 08:53:42 PDT --- Is the desktop locked up when this happens (i.e., can you still interact with apps)? Please attach your xorg log and dmesg.
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #3 from Mjules mjulien.m@gmail.com 2010-08-09 09:22:12 PDT --- Hi, 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.
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #4 from Mjules mjulien.m@gmail.com 2010-08-09 09:27:05 PDT --- Created an attachment (id=37730) --> (https://bugs.freedesktop.org/attachment.cgi?id=37730) dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #5 from Mjules mjulien.m@gmail.com 2010-08-09 09:27:36 PDT --- Created an attachment (id=37731) --> (https://bugs.freedesktop.org/attachment.cgi?id=37731) xorg.log
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #6 from Mjules mjulien.m@gmail.com 2010-08-09 12:49:31 PDT --- My bisection point to commit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=...
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
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #7 from Nicolas Kaiser nikai@nikai.net 2010-08-09 14:48:42 PDT --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=29433
--- Comment #8 from Mjules mjulien.m@gmail.com 2010-08-11 09:24:59 PDT --- (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).
https://bugs.freedesktop.org/show_bug.cgi?id=29433
Alex Deucher agd5f@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE
--- Comment #9 from Alex Deucher agd5f@yahoo.com 2010-08-12 15:08:39 PDT ---
*** This bug has been marked as a duplicate of bug 29536 ***
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org