| Summary: | Lagging mouse cursor | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Lars Ivar Igesund <larsivar> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | gibbsangel |
| Priority: | NOR | ||
| Version First Reported In: | 4.10.3 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Lars Ivar Igesund
2013-06-04 10:47:17 UTC
I should add that today I upgraded to 4.10.3 via the ppa, and this did not help. Does suspending compositing help? (Shift+Alt+F12) Unless the zoom effect is active, the cursor (ie. the "real" cursor) is drawn directly into the framebuffer and usually in hardware. Check your /var/log/Xorg.0.log - nvidia calls it "silken" mouse You'll rather perceive some change in the mouse acceleration settings or it's a bug in the kernel/X11. -> "kcmshell4 mouse" (In reply to comment #2) > Does suspending compositing help? (Shift+Alt+F12) Not that I can see. (I had already tried this, just forgot to mention it). > Unless the zoom effect is active, the cursor (ie. the "real" cursor) is > drawn directly into the framebuffer and usually in hardware. > Check your /var/log/Xorg.0.log - nvidia calls it "silken" mouse log has NVIDIA(0): Silken mouse enabled I can find no obvious errors in the Xorg log related to that or mouse in general. > You'll rather perceive some change in the mouse acceleration settings or > it's a bug in the kernel/X11. -> "kcmshell4 mouse" Changing those settings changes the behaviour of the cursor, i.e. moves faster, but the cursor still lags. Some additional observations; logging out doesn't fix anything, and neither does a restart of lightdm (sudo lightdm stop), and so after logging in and out, the cursor lags also on the log in screen. Rebooting fixes it for the login screen again. Now some interesting observations; when logging in, the mouse pointer is perfectly responsive up to a certain point which is after the backgrounds are shown, but before the setup is fully completed (for a second, this led me to think that it was a problem with establishing the network connection as the issue coincided with the link up, but it was just a red herring.) Further testing on this shows that if I disable desktop effects at startup, then I have no issues whatsoever, even if I use Shift+Alt+F12 to start desktop effects a bit later. However, if the desktop effects are enabled at startup, then the lagging starts at some point just before logging in is fully completed. This means that I have a perfectly fine workaround since I rarely actually restarts this computer (and also don't actually need the desktop effects), but that there possibly is a startup issue somewhere in the desktop effects/composition part. I see now that the Zoom effect is on by default - I will try to see how turning that off affects this tomorrow, I don't know that I've used it in any case. (In reply to comment #3) > (In reply to comment #2) > > Does suspending compositing help? (Shift+Alt+F12) > Not that I can see. (I had already tried this, just forgot to mention it). Certainly not kwin related then. > Changing those settings changes the behaviour of the cursor, i.e. moves > faster, but the cursor still lags. Can you please elaborate on "lag" then? Visual thing (leaving a trace) or when you push it initially it takes a moment to start movement on screen etc. > does a restart of lightdm (sudo lightdm stop), and so after logging in and > out, the cursor lags also on the log in screen. Rebooting fixes it for the > login screen again. -> rather a kernel issue then. Try unloading the nvidia module after stopping the DM, then start the DM again (should auto-load the module but you can try by hand) If that doesn't change anything it'll be rather around usb_*hid > but that there possibly is a startup issue somewhere in the desktop > effects/composition part. Accessing GL (tried switching to XRender compositing for consequences?) might "somehow" get the nvidia kernel module into a weird condition -> check reloading the module and/or up/downgrading the nvidia blob. (In reply to comment #4) > I see now that the Zoom effect is on by default loaded does not mean in use (when zooming and scaling the cursor the cursor has to be replaced by a texture and the actual cursor is hidden) From your prev comment, i quite doubt that this has any relation. Thank you for your comments. I didn't have much time to look further into this before now when even the workaround described above stopped working, this after yet another kernel update by Ubuntu (3.8.0-25). So I removed the latest kernels, and reinstalled the one I had before these problems started, 3.8.0-19, and it now seems to work perfectly again. So presumably some sort of interaction between the kernel and nvidia blob causes this issue, even if I can find no obvious trace of it in any of my logs. What I do know, is that this system requires the irqpoll kernel parameter, so I suppose that could cause certain instability in this area. IIRC the graphics wouldn't start at all without it. If I find the inclination, I may report this issue to Ubuntu, but for now feel free to close this illadvised bug report :) Stupid question: aboutwhat kind of "mouse" do we talk here? * usb attached mouse * ps/2 attached mouse * touchpad - synaptics? irqpoll is "intended to get systems with badly broken firmware running" - requiring that parameter is no good sign at all. It's not necessarily the nvidia blob, but you can try nouveau to check that. It is a USB attached mouse, standard Dell. I don't remember the exact issues, this was back in early April, but I was not able to get X up and running without irqpoll, something that appeared to apply both to the USB installer image, and the final installation, although manifested and different ways IIRC. The machine is a rather high end Dell workstation (Precision T5600) with a bunch of funny controllers including RAID, so I wouldn't be surprised if there is one or two firmware issues. I suppose though, that it is possible that whatever made irqpoll necessary in the first place, is fixed or similar in more recent kernels in such a way that irqpoll now becomes a problem - I believe I saw a (non-graphics related) anomaly in dmesg earlier today, before I downgraded, that I don't see now. Maybe I'll test that the next time the kernel is updated. But for now, and since this is exclusively a within the office work computer, I cannot spend a whole lot of time testing out an issue that isn't currently disrupting my work. Constant lagging and incorrect brush/paint options when used. |