Version: unknown (using 4.3.4 (KDE 4.3.4), Debian packages) Compiler: cc OS: Linux (x86_64) release 2.6.32-trunk-amd64 With gestures enabled and mouse button = 3 (left button), if I hold the left button and clock the middle botton (in dolphin, konqueror, and some others apps) then I can only emit mouse actions in the current widget. I can't select elements in any other window with the mouse (keyboard works normally). The mouse works properly again when I restart the session. How to Reproduce: - Enable mouse gestures and set button = 3 - Hold left button and click middle button in some window, release. - You can't click any other window.
Same problem with button = 2. Same problem in a PC and a laptop (mouse and touchpad), both with debian sid.
I get the same problem but with for a different cause. My gesture button is right click. If I hold down the right click button without moving the mouse, then when i release the button, only one window gets focus. If I try to click on other windows then they do not respond. I did a little debugging and found by modifying the kwin mousemark plugin that when this occurs, the previous right mouse button state and current right mouse state are both set to 1 even though I am not clicking anywhere. The only solution to this problem that I've found is by logging out and logging back in. (In reply to comment #0) > Version: unknown (using 4.3.4 (KDE 4.3.4), Debian packages) > Compiler: cc > OS: Linux (x86_64) release 2.6.32-trunk-amd64 > > With gestures enabled and mouse button = 3 (left button), if I hold the left > button and clock the middle botton (in dolphin, konqueror, and some others > apps) then I can only emit mouse actions in the current widget. I can't select > elements in any other window with the mouse (keyboard works normally). The > mouse works properly again when I restart the session. > > How to Reproduce: > - Enable mouse gestures and set button = 3 > - Hold left button and click middle button in some window, release. > - You can't click any other window.
I've got the same problem with KDE 4.4.2 (on Kubuntu 10.04). My gesture button is number 2 (middle button), and if I hold it down without moving the mouse and then release it, the problem condition starts. But if I move the mouse while holding the button, the problem condition does not start (the movement may be a valid gesture e.g. 'Back' or just random moving). When I say the 'problem condition starts', I mean that the button release event is somehow missed, and the system considers the button being down forever. Then when I click some window with button 1, the mouse is grabbed by that window forever since the automatic ungrab at button release can't take place when other buttons are down. A way to recover is to issue a fake button release event with the following command (you may need to install the xdotool package first) xdotool mouseup 2 After this fake button release command the mouse works normally again. So it is not necessary to restart the X server in order to recover. Now, I'm not familiar with KDE internals and the gesture framework, but I guess that when button 2 has been defined as the gesture button, KDE somehow 'steals' the press and release events for the button if there is mouse movement between them. But if the mouse doesn't move, the gesture system generates a fake press and release event for the active window, giving it the impression of a normal click so that it can perform its original button 2 action. This works OK with a fast click, but with a slow click where the button is held e.g. for a second the fake button release event doesn't seem to be generated (this can be observed with the xinput utility at least). I guess the logic in recognizing gestures and generating fake events is somehow flawed.
Thanks! Your fix does work. No need to logout and login again ;) Since you seem to have some idea of what's going on you may want to look at the source code responsible. I've tracked down to the file where I think the problem may lie. Take a look if you wish: http://websvn.kde.org/trunk/KDE/kdebase/workspace/khotkeys/libkhotkeysprivate/triggers/gestures.cpp?view=markup (In reply to comment #3) > I've got the same problem with KDE 4.4.2 (on Kubuntu 10.04). My gesture button > is number 2 (middle button), and if I hold it down without moving the mouse and > then release it, the problem condition starts. But if I move the mouse while > holding the button, the problem condition does not start (the movement may be a > valid gesture e.g. 'Back' or just random moving). > > When I say the 'problem condition starts', I mean that the button release event > is somehow missed, and the system considers the button being down forever. Then > when I click some window with button 1, the mouse is grabbed by that window > forever since the automatic ungrab at button release can't take place when > other buttons are down. > > A way to recover is to issue a fake button release event with the following > command (you may need to install the xdotool package first) > > xdotool mouseup 2 > > After this fake button release command the mouse works normally again. So it is > not necessary to restart the X server in order to recover. > > Now, I'm not familiar with KDE internals and the gesture framework, but I guess > that when button 2 has been defined as the gesture button, KDE somehow 'steals' > the press and release events for the button if there is mouse movement between > them. But if the mouse doesn't move, the gesture system generates a fake press > and release event for the active window, giving it the impression of a normal > click so that it can perform its original button 2 action. This works OK with a > fast click, but with a slow click where the button is held e.g. for a second > the fake button release event doesn't seem to be generated (this can be > observed with the xinput utility at least). I guess the logic in recognizing > gestures and generating fake events is somehow flawed.
Thanks for pointing out the source file. My best guess is that within function Gesture::stroke_timeout() the call mouse_replay( false ); should actually be mouse_replay( true ); If I understood correctly, the mouse_replay() function sends a fake button press event, and also a button release event iff the boolean parameter is 'true'. I suppose the button release is required in order to not leave the button in a 'down' state. However, that code line seems to be very old in the revision history, so it may also be that older Xserver versions have been more tolerant to leaving the button down with a fake event, and the problem would only occur with a more recent Xserver version. I've got version 1.7.6 myself.
> However, that code line seems to be very old in the revision history, so it may > also be that older Xserver versions have been more tolerant to leaving the > button down with a fake event, and the problem would only occur with a more > recent Xserver version. I've got version 1.7.6 myself. Actually a newer Xserver version could be the problem. I never experienced this issue with kubuntu 9.10 (xserver 1.6.4) but when I switched to arch (xorg 1.7.3) this issue started occurring. Here are the changes that occured from 1.6 to 1.7: http://www.x.org/wiki/Releases/7.5 > mouse_replay( false ); > should actually be > mouse_replay( true ); I tried making this change and it does work. However then the timeout causes some undesired behaviour. So the solution is to either 1 - the apply the above change and change the timeout behaviour, or 2 - the apply the above change and remove the timeout code, or 3 - find the reason why the change from xserver 1.6 to 1.7 caused this regression I think going with number 1 is best
This has bitten me too but xdotool mouseup 3 worked. And yes you need to press that button and another together to trigger the bug.
Is there a patch working well?
There is no patch that I am aware of. However you can minimise the chance of the bug happening by setting the gesture timeout to 1000ms.
This seems to be a duplicate of bug 173606, for which there is a fix in KDE 4.5.
Yes, it seems to be the same bug (at least from comment 6) and it seems solved in 4.5.