Ubuntu

Comment 33 for bug 764330

I've successfully narrowed down the cause of this, and found a workaround - for my systems. I'm unsure if this will fix things for anyone else, however. I did find some items surprising here, and they may warrant a deeper look.

This all came down to USB HID mouse sampling rates. The logitech reports a bInterval of 1, which is 1000Mhz. For whatever reason (this is likely a bug, I would imagine?) compiz appears to be doing work on every mouse poll. 1000 times/sec = you get stuttering going on. At least in my case.

I also noticed throughout this that my Nvidia card was on APIC interrupts - while this did not end up being the root cause, it's certainly not good. Check that out as well perhaps, fix is:

options nvidia-current NVreg_EnableMSI=1 in /etc/modprobe.d/nvidia.conf

For now, my workaround on the performance issue is to simply limit mouse polling to something sane. This is done by creating a file (anything will do really) in /etc/modprobe.d/usbhid.conf

Add:
options usbhid mousepoll=10

- this is 125mhz, next up is 8, 6, 4, 2, and so on. Go with the lowest you enjoy - honestly I'm fine personally with 10 or 8.

I do wonder how many laptops (as reported here) utilize USB-based trackpads? I would imagine this would contribute to quite a bit of battery drain in some use cases. Good howto is here for further reading: http://wiki.quakeworld.nu/Howto_customise_mouse_polling_rate

I can't imagine there is much benefit to compiz attempting to render frames (or otherwise "do stuff") faster than a certain fail-safe. At least there should be a configured maximum somewhere - as I don't think 1000 frames/second is truly needed for my desktop window redraws :) I would imagine this bug exhibits itself more on nvidia hardware, due to needing vsync turned off as well, but that's rampant speculation.

Hopefully this helps someone out there!