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]
Can you bisect to see what commit caused this? There haven't been any changes to the cursor code in quite a while.
Is the desktop locked up when this happens (i.e., can you still interact with apps)? Please attach your xorg log and dmesg.
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.
Created attachment 37730 [details] dmesg
Created attachment 37731 [details] xorg.log
My bisection point to commit : http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=eb1f8e4f3be898df808e2dfc131099f5831d491d 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
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.
(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).
*** 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.