Bug 238431 - Kwin4 mouse pointer becomes unresposive, but wheel on mouse still remains active
Summary: Kwin4 mouse pointer becomes unresposive, but wheel on mouse still remains active
Status: RESOLVED UNMAINTAINED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_khotkeys (show other bugs)
Version: 5.20.3
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Jansen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-21 20:47 UTC by Toure
Modified: 2024-03-04 19:42 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Picture to illustrate the responsive parts of the screen. (5.19 KB, image/jpeg)
2017-03-02 10:44 UTC, Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Toure 2010-05-21 20:47:15 UTC
Version:            (using KDE 4.4.3)
OS:                Linux
Installed from:    Ubuntu Packages

When using the desktop the mouse will on occation become unresponsive in regards to interacting with the desktop. The wheel remains active and I can cycle through the desktops with it, but the pointer itself will not interact with anything on the desktop. The keyboard remains functional as the shortcuts still work. I switch to a terminal (alt+ctrl+F3) and the mouse is active with the use of gpm. I have restarted plasma and still no joy, the only fix to remove this state is to log off and resume the session.
Comment 1 Thomas Lübking 2010-05-21 21:10:19 UTC
does this only affect the desktop and not other windows?
can you use the mouse to set the input (kbd) focus to another window?
Comment 2 Toure Dunnon 2010-05-21 21:13:42 UTC
I should have stated desktop and windows on the desktop.
Comment 3 Martin Flöser 2010-05-23 16:43:07 UTC
The bug sounds similar to bug #236832 - could it be related?
Comment 4 Thomas Lübking 2010-05-23 16:56:23 UTC
iff the pointer is grabbed, the wheel shouldn't work either.
to check whether the pointer is grabbed, try

   export DISPLAY:=0
   xprop

from eg. VT1 - if the pointer is grabbed, you'll receive a notice about that. ("xprop: error: Can't grab the mouse."), if not, you can switch back to X11 (VT7) and click some window (the pointer became a "+" meanwhile)
Comment 5 Toure 2010-05-25 03:59:59 UTC
Thanks, I will give that a try the next time this happens.
Comment 6 Toure 2010-06-01 18:22:24 UTC
So guys I think I figured out how to reproduce the problem. It seems only to happen with gestures enabled, if I am using gestures in konqueror after about an hour or so (its pretty sporadic).
Comment 7 Martin Flöser 2010-06-10 21:46:35 UTC
I hope this is the correct component for mouse gestures. If not sorry and please reassign :-)
Comment 8 chx1975 2012-12-14 03:24:14 UTC
I can confirm this on KDE 4.9. I mapped XF86LogGrabInfo to the menu key (135) and managed to get these reports:

[297685.310] (II) Printing all currently active device grabs:
[297685.310] Active grab 0x5200000 (core) on device 'Virtual core pointer' (2):
[297685.310]       client pid 25164 /opt/google/chrome/chrom 
[297685.310]       at 297514999 (from passive grab) (implicit) (device thawed, state 1)
[297685.310]         core event mask 0x63807f
[297685.310]       passive grab type 4, detail 0x0, activating key 0
[297685.310]       owner-events false, kb 1 ptr 1, confine 0, cursor 0x0
[297685.310] (II) End list of active device grabs

[285265.365] Active grab 0x4200000 (core) on device 'Virtual core pointer' (2):
[285265.365]       client pid 21657 kdeinit4: konsole [kdeinit] -session 10e5d3ab7200013553349450 
[285265.365]       at 285158360 (from passive grab) (implicit) (device thawed, state 1)
[285265.365]         core event mask 0x62e07f
[285265.365]       passive grab type 4, detail 0x0, activating key 0
[285265.365]       owner-events false, kb 1 ptr 1, confine 0, cursor 0x0
[285265.365] (II) End list of active device grabs
Comment 9 chx1975 2012-12-14 03:25:16 UTC
These were separate occassions because when this happens only an X restart helps. Quitting the app holding the grab merely transfers it to another.
Comment 10 o2029162 2012-12-16 12:07:05 UTC
I can confirm this, I'm having the same issue.

After using a few gestures (it's pretty difficult to guess exactly when/why it happens) the mouse focus gets grabbed in some window and closing it makes the grab move to another window. I've tried restarting kwin with no success.

I'm using KDE 4.9.4 in ArchLinux, my focus policy is sloppy focus and I'm using the radeon driver.

I think this began to happen to me in 4.9.2 or 4.9.3, but not sure.
Comment 11 chx1975 2012-12-16 14:33:06 UTC
I find it interesting both of us have ArchLinux. But then again if we were using Ubuntu or we'd be using the downstream bug tracker perhaps. And yes this is somewhat recent.
Comment 12 chx1975 2012-12-16 15:09:08 UTC
And, I guess only Arch is using KDE 4.9 :)
Comment 13 chx1975 2012-12-17 02:20:32 UTC
I found an old, similar bug https://bugs.kde.org/show_bug.cgi?id=173606 and a duplicate of it at https://bugs.kde.org/show_bug.cgi?id=224712 where Xavier Aragon suggested   xdotool mouseup 2 which works. 2 is the number of the button. You might need 3.
Comment 14 o2029162 2012-12-17 08:18:13 UTC
Thank you so much for the tip.

It will do the work pretty well while the bug is open
Comment 15 cosmoslx lin 2013-02-22 01:49:22 UTC
Version: (using KDE 4.10.0) 
Compiler: gcc-4.6.3
OS: Gentoo Linux 
Installed from: Gentoo Portage

Reproduce: always

How to Reproduce: 
     1. Enable mouse gestures and set button = 3
     2. Hold right button long enough, release. 
     3. You can't click any other window, but you mouse pointer can move and the keyboard works.

When I update from 4.9.5 to 4.10.0, I notice this bug and confirm it.
Using 4.9.5, I don't notice this bug. I always use gesture.

As mention by chx1975, thers are similar old bugs
https://bugs.kde.org/show_bug.cgi?id=173606 
https://bugs.kde.org/show_bug.cgi?id=224712

I try chx1975' s suggestion,  it work.  maybe this is a regression?
Comment 16 m00ki 2013-09-18 21:00:41 UTC
I can confirm this bug, using OpenSuSE 12.3 x64, KDE 4.11 and it seems to be a problem related to kwin only. Recently I switched from Geforce to RadeonHD using the proprietary driver in both cases and the bug remained. When kwin suddenly grab the mouse and refuses to let it go,  openbox --replace is the only option to get the desktop functional again.

My pointing devices (in case it could be useful):
Apple Magic Trackpad with touchegg for gesture support
Madcatz R.A.T.5 with xorg.conf workaround to map the buttons correctly.
Comment 17 xisco 2014-04-14 08:07:48 UTC
I can confirm this bug, using Opensuse 13.1 x64, KDE 4.12.4, I don't know where is the problem as it is random, can pass days without seeing it.
Keyboard works but mouse only moves cursor, no responte to mouse clicks, only solution since now is reestart kde
Semitower PC with nvidia graphics card and usb mouse
Comment 18 Mathieu Jobin 2015-03-05 16:48:17 UTC
this happened to me after a system upgrade and a reboot on Kubuntu 14.04
other window managers not affected.
Comment 19 Mathieu Jobin 2015-03-05 21:29:04 UTC
I should mention this is quite major, as I can no longer use KDE.
Comment 20 m00ki 2015-03-05 22:11:35 UTC
Meanwhile, I have solved the issue on my system: It was related to the madcatz rat 5 mouse which  made some modification to the xorg.conf file necessary (to map some extra buttons). Without this mouse and those modifications, I have not seen this error so far.
Comment 21 Mathieu Jobin 2015-03-22 00:28:41 UTC
i don't have such a mouse, neither I have a xorg.conf file anymore.

I run Kubuntu 15.04, upgraded packages to the latest.

tried both nvidia and nouveau driver.

KDE unusable, I miss it
Comment 22 Mathieu Jobin 2015-04-07 23:39:17 UTC
on my plasma 5 desktop, it was freezing after couple of minutes of usage.
I moved the .cache folder to .cache-moved, and my desktop got stable again...

on my KDE4 Kubuntu 14.04 VM, my mouse click wasn't working upon login.
i got it back after disabling dual screen.

thanks
Comment 23 Alex 2017-03-02 10:44:29 UTC
Created attachment 104313 [details]
Picture to illustrate the responsive parts of the screen.

Hi.

I've the same issue here (ArchLinux with kde-applications-meta 16.12-1, plasma-mata 5.9-1).

My system is running in a VM and now there is only a part of the screen unresponsive to the mouse - when i resize my VM-window then the new parts are responsive.

For example: when the issue occured i had a resolution of 800x600, when i increase my resolution to FullHD the new parts are responsive - leaving only the initial 800x600 (red) area dead.

Maybe this information helps to track down the issue!?
Comment 24 Nate Graham 2024-03-04 19:42:08 UTC
As announced in https://pointieststick.com/2023/07/26/what-we-plan-to-remove-in-plasma-6/ and https://community.kde.org/Plasma/Plasma_6#Removals, I'm afraid KHotKeys has reached end-of-life in Plasma 6. Accordingly, all bug reports and feature requests for it must be closed now.

Most of what KHotKeys could do can already be done with the newer KGlobalAccel system in Plasma 6. A few features such as mouse gestures and triggering conditions based on changes to window states are not yet implemented in the new system. These will be added in the future if and when resources materialize for them, and/or when a kind soul submits patches to implement them! :) Meanwhile, the 3rd-party "Mouse Actions" app (https://github.com/jersou/mouse-actions) may be usable for implementing your own mouse gestures again.

Thanks for your understanding, everyone.