Something weird has been occurring with some frequency lately. When I am in a middle of a disk-intesive task (ie moving 10GB of files from one partition to another), oftentimes I would either either completely lose the function of my mouse buttons or they would start behaving erratically. Scrolling remains unaffected though, but present windows would not initiate when I scroll to a hotcorner nor could I select any other open windows because click behavior is lost (duh). Alt-tabbing still works. Often, when I try to click a window near the top of the screen, launcher(s) from cairo-dock (screen bottom) are brought up and launched, leading to a desktop cluttered with unwanted programs and a tedious exercise of killing those apps (alt-tab to konsole, killall -9 <program name>.

One relevent point is that I have mouse gestures enabled in "input actions". I read somewhere (irc?) that people with gestures enabled see this strange activity. Keyboard and keyboard bindings still work though, which allows me to alt-tab to programs and save sessions for those that are responsive to keyboard inputs. In order to recover normal mouse functionality, I have to completely restart X (ctrl-alt-backspace). Others like myself do not enjoy having our workflows disrupted. Could be a potential showstopper.

Arch64, xserver versions 1.7.6-1.8.1, KDE 4.4.4, QT 4.6.3, opensource radeon drivers

EDIT: found the bug report here - http://bugs.kde.org/show_bug.cgi?id=173606
Like one poster said, it reminds me of the Windows behavior "save early, save often" most notably seen and, sadly, experienced during the WindowsMe era.

I must say that I've enabled gestures from kde 4.2.0 (kubuntu64) and have used them extensively and haven't experienced this bug until kde 4.4.x (arch64).

Are you sure that applications are not being swapped out to disk? If the Kernel swaps out the processes that run mouse gestures, etc. then this behaviour is possible.

Your bug description doesn't completely fit what I've been experiencing and reading about, but you probably mean the same problem. I've been discussing about this bug and trying to chase it down for a long time. Until I read the bug report you're linking to I thought that it wasn't a problem in KDE because (among other reasons) Gnomies experienced something similar.

Well, thanks to one comment in that bug report I was finally able to reliably reproduce the bug. I found a ridiculously simple fix within 10 minutes, but I'm not _quite_ sure if this is ready to commit; I'll wait for approval by the maintainer of KHotkeys.

If all goes well it might make it into KDE 4.5.0. Let's cross our fingers that there's not more than one cause for the bug.

Eh, sorry for being a little too euphoric a little too early.
I didn't even need the maintainer's review to notice this can't be the right way to fix it because it breaks Drag'n'Drop with the gesture button. Looks like it's not KHotkeys' fault after all, this will make all of this much harder and slower :(

Looks like it is a Xorg regression and it has been reported upstream. A patch looks forthcoming. Thanks to Frank for alerting the Xorg devs.

"Frank" is me ;) I've been awfully inconsistent with my identities in the KDE community.
Anyway, it looks like the patch will make it into xorg-server 1.9. It's a little hard to tell because of the git development model, that's why I haven't closed the bug report yet.