Mouse events fail frequently and unpredictably, requiring kwin restart

[Patrick Dawkins]

Binary package hint: kdebase-workspace

There is confusion between a number of related bugs (which didn't show up for me in "Do any of the following bugs..."). Bug #478464 seems most similar to this but that's dubiously marked as a duplicate of bug #41301.

DESCRIPTION
It occurs within a few minutes (usually sooner) after starting KDE or restarting kwin with "kwin --replace". The mouse cursor continues to move where it should, but clicking either does nothing or affects an unexpected (inactive) window, and gestures such as pushing into the desktop corners also do nothing. It's as if kwin thinks the mouse cursor is frozen somewhere other than where it appears.

Everything other than mouse events continues to work as expected: controlling KDE with keyboard shortcuts shows that applications, compositing and desktop effects are all fine.

[Edit: it is NOT as if a phantom window/app is grabbing the mouse events, because as stated above, clicks occasionally still affect a real window for a short while, even if it's an inactive one.]

WORKAROUND
Restart kwin with "kwin --replace".

None of the workarounds mentioned in the discussion for bug #41301 work for this, which is why I think it's different.

BACKGROUND
I'm not running Xinerama or dual screens, I have a USB mouse which works perfectly on my other machine, my Kubuntu 9.10 retains most of its default settings, windows are set to "Click to Focus", and my graphics card is nVidia GeForce 6100 with the nvidia-glx-185 driver.

I run regular apt updates, and first noticed this bug on 8 Jan 2010, having run KDE with very few problems for several months. I think the automatic updates on 8 Jan were for Firefox and GIMP (upgrades), but this bug occurs whether or not Firefox or GIMP are running. I have not made any configuration changes recently.

ProblemType: Bug
Architecture: amd64
Date: Sun Jan 10 13:44:24 2010
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/bin/kwin
NonfreeKernelModules: nvidia
Package: kde-window-manager 4:4.3.2-0ubuntu7.1
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
 LANGUAGE=
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: kdebase-workspace
Uname: Linux 2.6.31-17-generic x86_64

[Patrick Dawkins (pjcdawkins)]

This bug is happening all the time (I'm using Alt+F2 then "kwin --replace" more or less every time I want to use the mouse) which is quite frustrating. It's still unpredictable though.

I have tried disabling compositing and changing various display options, and I've tried keeping an eye on what processes are running when the mouse events fail - this yields no clues for me.

[V (antiauth)]

I have the exact same problem and I can assure that it's not a hardware problem since I used numpad to check if the problem was caused by the usb wireless mouse.

My graphics card is nvidia GeForce 6800LE with nvidia-glx-185 driver. The install is a fresh and updated kubuntu 9.10 (2.6.31-19-generic).

I tried to disable compositing and play with focus settings but without a result. Now I'm going to use a non-proprietary driver (or the nvidia-173) to see if the problem remains. Maybe it's an X.org bug

Help is appreciated

[Jonathan Kolberg (bulldog98)]

For me it also happens, but only on my computer with the nvidia driver. My computer with Intel works, so it could be nvidia specific.

[Patrick Dawkins (pjcdawkins)]

Jonathan, is that also the nvidia-glx-185 driver, and/or also an nVidia GeForce 6000 series card?

[Jonathan Kolberg (bulldog98)]

I use nvidea-current under lucid, but I don't know the command to find out the card, yet.

[Patrick Dawkins (pjcdawkins)]

> I don't know the command to find out the card, yet.

lspci -v | grep VGA

[Jonathan Kolberg (bulldog98)]

ok thanks.

here the output:
02:00.0 VGA compatible controller: nVidia Corporation C77 [GeForce 8100 / nForce 720a] (rev a2)

hope this will help

[Patrick Dawkins (pjcdawkins)]

Jonathan and Vasilis are you also on Kubuntu 64-bit?

The more information we provide perhaps the quicker someone in the know will respond!

[V (antiauth)]

No, I'm on Kubuntu 32-bit. I tried also the nv driver without a change. Seems like a cross-distro problem for my system. I've tried openSUSE 11.2 (both KDE4 and GNOME) and also the KDE-testing Debian. I don't have the time at the moment to downgrade to an old Ubuntu distro (with an older version of Xorg) -but when I manage it, I'll post the results.

[Alex Rovner (alexrovner)]

I am on 64 bit 9.10 using gnome with same problem. Cant click on things.

[RK (kubuntu-rk)]

I have this bug as well, since upgrading to lucid, using ATI (no more nvidia, yay), kernel 2.6.33, kde 4.4. However, for me, restartin kwin does not help at all - only restarting X.

[plusplus (strosset)]

Same issue here since an upgrade last week. This is with kubuntu 9.10 64-bit, kde 4.3.5. After a cold boot I have to logout/login to have the mouse working again in kde.

[Patrick Dawkins (pjcdawkins)]

Well, since reporting this bug I gave up and installed a new Ubuntu 9.10 / GNOME system.

Now about six weeks later, I've got it again, only it seems to be even worse.

Other very important things also stop working:
Alt+F1 highlights the text "Applications" but the menu does not open.
Alt+Tab does nothing.
Alt+Space in a window does nothing.
The Alt key is ignored in global shortcuts: I've set Ctrl+Alt+T to open a Terminal in the GNOME Keyboard Shortcuts, but from Firefox it just opens a new tab (which should be Ctrl+T).

[Jonathan Thomas (echidnaman)]

This is probably a bug in the X stack, somewhere. Bumping over there for triage.

[plusplus (strosset)]

Well, the problem went away when I switched kdm to a themed appearance. With the non-themed display in kdm I had this issue both with kde and icewm.

[Xavier Aragon (xarax-lp)]

The KDE bug tracker has the following bug report about a situation which leads to similar mouse problems as described here. That problem occurs only if the mouse gestures feature has been turned on.

    https://bugs.kde.org/show_bug.cgi?id=224712

There is also a method for recovering from the problem without restarting the X session by issuing the following command, which sends a fake mouse button 2 release event:

    xdotool mouseup 2

[Martin Dreher (mercutio-design)]

Also affects Kubuntu 10.04 LTS!

Sometimes multiple right clicks solve the issue, thought.

[Patrick Dawkins (pjcdawkins)]

@ Martin Dreher

I can confirm there is a similar symptom, possibly of the same disease, in Ubuntu 10.04 LTS.

It's milder but still abominable. The way I have it, in GNOME, the mouse events end up working only in one window (or panel), but right-clicking once in that window allows you to click on another window. The new window will then grab the mouse events, and so on...

[Martin Dreher (mercutio-design)]

@ Patrick Dawkins

Yes, after trying around I found out the same thing!

For example, when I click on the App Launcher in the taskbar, the mouse will not actually work in the applauncher unless I right-click on the symbol or anywhere in the taskbar again..

Quite annoying! I really hope there will be a patch for this because I actually was still in the process of switching to Ubuntu and now I find myself going back to Windows which is so slow!

[Gregor Kališnik (gregor-podnapisi)]

Hi. I use Gentoo with xorg-server 1.7.x and evdev 2.4.

The behaviour is like this:

When I do any mouse buttons events on a window (scroll, click, etc.), all mouse events are visible only to that window (even position). To "release" the lock, I have to right click on that window. And if I click on a different window, only that window then receives the mouse events.

Can this be anykind of a feature, that is enabled by default?

Best regards.

[Patrick Dawkins (pjcdawkins)]

Since comment #18 we're talking about a different symptom to the original bug, although it looks like it could well be the same disease (it affects both KDE and GNOME).

I occasionally get it after booting up, but then if I log out and log in again the problem goes away. So it might be something to do with a program running after logging in, or something to do with the CPU/memory load of such programs? The Ubuntu One client goes mad (presumably syncing) when I log in for the first time. Try (1) logging in again (starting a new session) and/or (2) disabling a few start-up programs.

[Gregor Kališnik (gregor-podnapisi)]

Yes. I figured that far. Now I'm going to downgrade to xorg-server 1.6 (since ati-drivers-10.4 are little buggy).

Thanks for info.

[Martin St. (hurzl)]

I have a similar problem with 10.04 LTS and KDE.
First login after boot:
Sometimes only the menus of certain applications can be clicked, but window move or resize with the mouse is not possible. I think only the left mouse button is affected. I tried to stop most of the kde processes, but this did not help. kwin --replace helps only for a few mouse clicks and then the problem occurs again.
If I logout and login again, the problem is vanished.
I'm using the nvidia-current driver and have a logitech wireless mouse.

[G Deola (coderedcomputing)]

Adding this as an additional bump to this bug, installed 10.04 and did not see this occur until I plugged in the logitech wireless mouse, now the touchpad no longer works, and the mouse is buggy. Seems to point to the logitech as a source?

[Rich Coe (codedr)]

I found this bug report when I was searching for a fix for a similar issue.
In my case all you have to do is move a window and then immediately click in another window.
There may be other ways to reproduce this.
Investigating the issue I found this patch:
     http://cgit.freedesktop.org/xorg/xserver/patch/?id=1884db430a5680e37e94726dff46686e2218d525
     Subject: Revert "dix: use the event mask of the grab for TryClientEvents."

I am using xorg-server-1.8.0 and found the issue was introduced in
xorg-server-1.6.3. The patch fix appears in xorg-server-1.8.2 and later.

[Michael Basse (michael-alpha-unix)]

Here is a patch which seems to solve the problems with the current x-server.

[Kevin BARREAU (kevinb-dev)]

When could we get the new X-Server on Ubuntu?
This problem is really annoying, and it has been reported on several different distro.

[Kevin BARREAU (kevinb-dev)]

By the way, I forgot to tell, that I encountered this bug on a fresh Natty 11.04 install with formated drive.

Few second after loging in, the mouse events are not taken into account, leaving the focus where you clicked before the bug triggers.
Then the mouse is like a cooling unit in the artic. It moves but click will not have any effect. kwin --replace will give an extra 5 sec of functionnality before going back to buggy state.

if anyhow I want to logout/reboot/shutdown, X seems to hang for ever on a black screen. Then
I ctrl+alt+F1 killall Xorg, and finally the Logout/reboot/shutdown go on and do what is expected.

After that It seems like the bug is killed, though I just experienced too few to be sure of that.

[Kevin BARREAU (kevinb-dev)]

Ok so I apology not to test and report it at first, but here is some important informations :

-My problem triggered when upgrade ubuntu last friday 10 June. Before, I used Natty KDE for few weeks without any hitch.

-I use my old usb Logitech wire-mouse, G5, when I plug it out the laptop touchpad runs perfectly. When I plug it in, both (touchpad & mouse) won't take left clicks.

Of course I tested the mouse on Mac, it works perefectly.

My problem's behaviour is extacly like this one, so I thought it would be related !

Anyway, I found a way to finally use again my lovely Ubuntu, which I was missing a lot since.

[essl (essl-main)]

Same here, all the clicks go to the previously focused window until right clicked (in a way that it will be registered in the previous window, clicking outside doesn't help), then the clicks are registered in the new window only. Closing previous window helps.
e.g.: chrome with gmail opened in a tab, going to another desktop/alt-tabbing to another window, clicking inside the shown window registers clicks in gmail, right-clicking where emails list suppose to be registers in gmail and doesn't release the "lock" clicking somewhere in the body or where chrome tabs/menus suppose to be pops-up a context menu and releases the lock, closing/killing chrome helps too. All the clicks after that register in the new window only...
Another scenario: when in not-maximized window, alt-tabbing/going to another desktop, clicking - all the clicks register in the previous window, right-clicking "outside" that window won't do anything, clicking inside releases the lock...

I'm pretty much sure that the reason right-click helps is that it creates the context menu, which is a window itself. So when a new window created it gets the focus and mouse clicks go there, clicking anywhere else closes the menu and window is destroyed, releasing that way the "lock". So any next window you click has the focus now...

My setup - openSuSE 12.1 64, X 1.10.4, KDE 4.7.2R5

[essl (essl-main)]

Just read comment #30... Re-plugging the mouse fixes the problem...

[Karoly Negyesi (karoly)]

I have added comments to https://bugs.kde.org/show_bug.cgi?id=238431 which might or might not be the correct bug to report on. xdotool mouseup 2 or xdotool mouseup 3 helps depending which mouse button up event gets lost.

[penalvch (penalvch)]

Patrick Dawkins, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p xserver-xorg-input-evdev REPLACE-WITH-BUG-NUMBER

Please note, given that the information from the prior release is already available, doing this on a release prior to the development one would not be helpful.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Patrick Dawkins (pjcdawkins)]

Thanks for checking. I can't reproduce this anymore. I no longer own the same hardware (I haven't done for a couple of years).

[penalvch (penalvch)]

Patrick Dawkins, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/505494/comments/35 regarding you no longer own the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.