Bug 76041 - windows + key combination sends an endless input if the key that is pressed
Summary: windows + key combination sends an endless input if the key that is pressed
Status: RESOLVED FIXED
Alias: None
Product: khotkeys
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: RedHat Enterprise Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Lubos Lunak
URL:
Keywords:
: 71831 74748 84222 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-02-24 17:43 UTC by zabilcm
Modified: 2005-05-30 15:27 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description zabilcm 2004-02-24 17:43:12 UTC
Version:           kde 3.2 (using KDE KDE 3.2.0)
Installed from:    RedHat RPMs
Compiler:          3.3.2 gcc version 3.3.2 20031022 (Red Hat Linux 3.3.2-1)
OS:          Linux

By default the following key combination was assigned for the run command dialog "windows+r" (I have configured my desktop with windows behavior)
Now on some key strokes of this combination I have noticed that after I press "windows+r" the r letter gets sent to the screen in an endless sequence until I cancel it with some other action. 
Suspecting this is some problem with my r key i assigned "window+i" to launch konqueror and again i get the same problem "sometimes" when i use the combination.
If i have the console open and I press "windows+i" 
iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii get's sent to the konsole until I cancel it by pressing some other key.
I never faced this problem when I used to run kde 3.1.4 on my system.

I run kde 3.2 on compaq presario 700 laptop.
Comment 1 Lubos Lunak 2004-02-24 18:04:35 UTC
Can you check if turning NumLock on or off has any effect on this problem?
Comment 2 zabilcm 2004-02-24 18:20:07 UTC
I have a compaq laptop. Numlock unfortunately seems to be absent in it.
Comment 3 Lubos Lunak 2004-02-25 08:49:46 UTC
You could try turning NumLock on using this utility: http://ktown.kde.org/~seli/numlockx/ . There's also a utility called KLeds which should show its status.
Comment 4 zabilcm 2004-03-01 19:48:10 UTC
Ok I know I am not experienced in this but out of curiosity could I ask if putting the num lock on will solve the problem ?
The problem is I am not able to locate a behavior that would replicate this defect more or less it occurs randomly. Will try numlockx and see if it occurs again.
Comment 5 zabilcm 2004-03-18 20:02:51 UTC
Ok i am able to replicate it (or so i think)
This happens while there is a delay is the loading of the "run dialog" (win+r)
when i click the win+r combination and I switch to another window before the run dialog appears (let's say some process was running in the background).
This has proved to be extremely dangerous for me because when this happens in the kmail window it opens an endless stream of reply windows.
I pray to God at night for this bug to dissapear.
Comment 6 Dima Ryazanov 2004-05-14 04:19:26 UTC
I don't even need to switch to another application. Very often, when I type something in Konsole and press Win-R for the first time after logging in, I get the same result. Good thing I'm using Win-R, and not Win-Enter.
Comment 7 Lubos Lunak 2004-09-15 12:31:21 UTC
Does your keyboard have at least CapsLock (or, not that I expect it, ScrollLock)? Can you try with that activated?
Comment 8 Dima Ryazanov 2004-11-08 09:06:35 UTC
NumLock does seem to make a difference. Usually, it happened to me at least once a day. With NumLock on, it's been working fine for a week.

Btw, normally (without NumLock), I can get an endless input with Win-somekey even if that combination is not assigned for any shortcut. It seems to happen if I release the key after I release Win, e.g. press Win, press R, release Win, release R.
Comment 9 Aaron J. Seigo 2004-11-08 22:22:01 UTC
CVS commit by aseigo: 

after discussions with Lubos, it was decided to just rm this "feature" due
to ongoing issues with it. Lubos sees more trouble with it than its worth,
and forsees ongoing bugs cropping up even if we manage to fix the current
spate. it's value is not commensurate.

BUG:76041
BUG:69411
BUG:85394


  M +0 -91     kbutton.cpp   1.18.6.3
  M +0 -2      kbutton.h   1.5.8.1


--- kdebase/kicker/buttons/kbutton.h  #1.5:1.5.8.1
@@ -46,6 +46,4 @@ protected:
     virtual void initPopup();
     virtual QString defaultIcon() const { return "go"; }
-
-    virtual bool x11Event( XEvent *event );
 };
 

--- kdebase/kicker/buttons/kbutton.cpp  #1.18.6.2:1.18.6.3
@@ -54,30 +54,4 @@ KButton::KButton( QWidget* parent )
     MenuManager::the()->setKButton(this);
     setIcon("kmenu");
-
-#if defined(HAVE_XTEST)
-    // Get the Win keycodes
-    // FIXME: This should be retrieved from KKeyServer, since the Win key might not be mapped to Super
-    g_keycodeForSuperL = XKeysymToKeycode( qt_xdisplay(), XK_Super_L );
-    g_keycodeForSuperR = XKeysymToKeycode( qt_xdisplay(), XK_Super_R );
-
-    // Make sure that the Win key is not in repeat-when-pressed mode
-    XKeyboardControl kbd;
-    kbd.auto_repeat_mode = AutoRepeatModeOff;
-    kbd.key = g_keycodeForSuperL;
-    XChangeKeyboardControl( qt_xdisplay(), KBKey | KBAutoRepeatMode, &kbd );
-    kbd.key = g_keycodeForSuperR;
-    XChangeKeyboardControl( qt_xdisplay(), KBKey | KBAutoRepeatMode, &kbd );
-
-    // Grab the Win keys
-    if( g_keycodeForSuperL || g_keycodeForSuperR ) {
-        //kdDebug(125) << "g_keycodeForSuperL = " << g_keycodeForSuperL
-        //    << ", g_keycodeForSuperR = " << g_keycodeForSuperR << endl;
-        if( g_keycodeForSuperL )
-            XGrabKey( qt_xdisplay(), g_keycodeForSuperL, 0, qt_xrootwin(), True, GrabModeAsync, GrabModeSync );
-        if( g_keycodeForSuperR )
-            XGrabKey( qt_xdisplay(), g_keycodeForSuperR, 0, qt_xrootwin(), True, GrabModeAsync, GrabModeSync );
-        kapp->installX11EventFilter( this );
-    }
-#endif
 }
 
@@ -103,67 +77,2 @@ void KButton::initPopup()
 }
 
-#if defined(HAVE_XTEST)
-extern Time qt_x_time;
-
-#define UNGRAB() \
-            XUngrabKeyboard( qt_xdisplay(), event->xkey.time ); \
-            XUngrabPointer( qt_xdisplay(), event->xkey.time ); \
-            s_bWatching = false
-
-bool KButton::x11Event( XEvent* event )
-{
-    static bool s_bWatching = false;
-    bool bHandled = false;
-
-    if( !s_bWatching ) {
-        if( event->type == KeyPress ) {
-            //kdDebug(125) << "key pressed: window " << event->xkey.window << endl;
-            // 115 = Super_L
-            if (event->xkey.state == 0 && event->xkey.keycode &&
-                (event->xkey.keycode == g_keycodeForSuperL ||
-                 event->xkey.keycode == g_keycodeForSuperR)) {
-                if( XGrabKeyboard(qt_xdisplay(), qt_xrootwin(), false, GrabModeAsync, GrabModeAsync, qt_x_time) == GrabSuccess ) {
-                    //kdDebug(125) << "grab!" << endl;
-                    XGrabPointer( qt_xdisplay(), qt_xrootwin(), false, ButtonPressMask | ButtonReleaseMask, GrabModeAsync, GrabModeAsync, None, None, qt_x_time );
-                    s_bWatching = true;
-                    bHandled = true;
-                }
-            }
-        }
-    }
-    else {
-        if( event->type == KeyPress ) {
-            UNGRAB();
-            XTestFakeKeyEvent( qt_xdisplay(), event->xkey.keycode, true, 0 );
-            //kdDebug(125) << "sent" << endl;
-            bHandled = true;
-        }
-        else if( event->type == KeyRelease ) {
-            UNGRAB();
-            if (event->xkey.keycode &&
-                (event->xkey.keycode == g_keycodeForSuperL ||
-                 event->xkey.keycode == g_keycodeForSuperR))
-            {
-                //kdDebug(125) << "Win released! " << popup()->isVisible() << endl;
-                if (popup()->isVisible())
-                    popup()->hide();
-                else
-                    slotExecMenu();
-            }
-            bHandled = true;
-        }
-        else if( event->type == ButtonPress || event->type == ButtonRelease ) {
-            UNGRAB();
-            XTestFakeButtonEvent( qt_xdisplay(), event->xbutton.button, event->type == ButtonPress, 0 );
-            bHandled = true;
-        }
-    }
-
-    return bHandled;
-}
-#else
-bool KButton::x11Event( XEvent* )
-{
-    return false;
-}
-#endif


Comment 10 Lubos Lunak 2004-11-19 19:31:16 UTC
*** Bug 71831 has been marked as a duplicate of this bug. ***
Comment 11 Lubos Lunak 2004-12-01 11:21:46 UTC
*** Bug 84222 has been marked as a duplicate of this bug. ***
Comment 12 Lubos Lunak 2005-05-30 15:27:15 UTC
*** Bug 74748 has been marked as a duplicate of this bug. ***