Version: (using KDE KDE 3.5.5) Installed from: Mandriva RPMs When an application hangs or take so long to do something, while handling a global shortcut, the keyboard remains grabbed by the application, making the keyboard unusable. Instances of this problem may be seen on the reports: #132595, #133755, #132991. Of course, the specific bugs on each application need to be fixed, but the way global shortcuts are implemented today make it too easy to a misbehaving application to make the whole KDE session unusable. Sometimes the hang isn't even a fault of the application (for example, when a NFS server goes down, and amarok is playing from a NFS mount). I am hit by this bug almost once every week, when using kopete or amarok shortcuts My feature request is that either: - The global shortcut implementation don't grab the keyboard (or make this configurable). I don't know if there is a real reason for grabbing the keyboard before the application handle the shortcut. Maybe there is a reason for this, then this couldn't be changed; and/or - Allow an application to tell kdelibs "I don't need the keyboard to be grabbed" for the cases where the action may need some time to be handled or when the keyboard grab isn't really needed by the application; and/or - Implement "keyboard grabbed for too much time" detection and remove the grab (possibly telling the user if this has happened), if the application is taking too long to handle the global shortcut; and/or - Other possible solutions for this problem you may suggest. I know about AllowDeactivateGrabs/AllowClosedownGrabs, but my feature request is about not having to remember and use Ctrl+Alt+KP_Multiply anymore. IMO, it the key sequence is not intuitive, and users aren't supposed to remember the sequence when their system is unusable (for example, I never remember what is the key sequence when I need it).
Given http://websvn.kde.org/trunk/KDE/kdelibs/kdeui/util/kglobalaccel_x11.cpp?rev=569619&view=log#rev243747 , which a) should avoid the problem you describe b) points out there are very likely X bugs in handling of global shortcuts, I recommend reporting this problem to X developers.
Thanks for the pointer. I am not a X expert, so I don't see right now how the change on rev243747 is related to my report. However, now that I see exactly the point where XUngrabKeyboard() happens, I will do some debugging to have a better understanding of what is causing the problem. As the keyboard is ungrabbed very soon, before KGlobalAccel::keyPressed() is called, It looks like the problem doesn't happen when the global shortcut handler takes too long, but when the application is not handling X11 events immediately. Please correct me if any of my assumptions is wrong. I will do some debugging and then report what I discover. If you think it is appropriate, you can assign the bug to me, as now I am volunteering to debug the issue. :)
any luck with investigation ? :)
bug 132595 and bug 132991 may well be the same as this
*** Bug 132991 has been marked as a duplicate of this bug. ***
I don't think #132991 should be marked as a dupe. As the original report in this bug says, the individual applications can fix their individual instances of this bug as well. Such bugs should be left open in each app.
i'd say this is the most annoying kde bug to date, given how stable it is in the 3.5 series... just now i got my box killed by this problem. system was pretty loaded, and i accidentally hit win+p (instead of win+o), which makes amarok hide/appear. probably because of the load, something on the sending end thought that amarok did not receive this signal, so it repeated it. now, having amarok constantly show and disappear only contributed to the load, which in turn made it unable to receive the signals timely, which in turn made sender resend them again, which made amarok... so i had a blinking amarok window, huge system load and non-working keyboard. might sound amusing, but annoyage factor was quite high. 1. can there be a central fix in kde ? 2. should there be anything fixed in xorg ? if so, i'll make sure to nag them as well; 3. can i somehow disable the resending of keyboard events ?
I had a stick of memory go bad and had to remove it, which reduced my system's memory by 256 MB. Now I am seeing swapping and higher CPU load, and while I hadn't encountered this bug in a long time, suddenly I am getting it again. When it happens, it seems that X constantly repeats the keypress event. Sometimes I can switch to another VT and run $(xev -display :0) and I can see that X is repeating the event that was passed to Amarok. When this happens, Amarok seems to receive the keypress just fine; for example, if it happens when I press the Next Track hotkey, Amarok will constantly skip to the next track. Even if I kill Amarok, though, it doesn't stop the repeating keypresses. I end up having to reboot, because if I just kill X, it messes up the VTs, and even after forcing a reload of the video driver kernel module, X still won't reload. This is a really bad bug. It can strike at the worst time, force a reboot, and possibly cause lost data as well.
damn. please, please, somebody tell me of some workaround, be it made in kde, xorg or whereever... the annoyance of this bug increases with every time i encounter it, which is much more often than i would like to.
Happens to me also with KDE 4.1 trunk. Keyboard freezes kinda randomly every once in a while. I could not see a relationship with keyboard shortcuts (I'm not using any). Restarting KDE fixes it.
*** Bug 156094 has been marked as a duplicate of this bug. ***
Hi, kdelibs (version 4 and earlier) is no longer maintained since a few years. KDE Frameworks 5 or 6 might already have implemented this wish. If not, please re-open against the matching framework if feasible or against the application that shows the issue. We then can still dispatch it to the right Bugzilla product or component. Greetings Christoph Cullmann