Bug 162144 - JuK multimedia keys as global shortcuts cause kded to crash
Summary: JuK multimedia keys as global shortcuts cause kded to crash
Status: RESOLVED FIXED
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kdeui (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: VHI crash
Target Milestone: ---
Assignee: Andreas Hartmetz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-05-16 01:47 UTC by Michael Pyne
Modified: 2008-07-05 02:00 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 Michael Pyne 2008-05-16 01:47:48 UTC
Version:            (using Devel)
Installed from:    Compiled sources
Compiler:          gcc 4.2.3 (Gentoo 4.2.3 p1.0) w/ mudflag and gentoo patches
OS:                Linux

JuK's multimedia shortcuts cause kded4 to crash on kded4 startup due to an assertion in kdeui/shortcuts/kdedglobalaccel.cpp:

@@ -398,7 +398,7 @@
             ad->isPresent = true;
             foreach (int key, ad->keys) {
                 if (key != 0) {
                     Q_ASSERT(d->keyToAction.value(key) == ad);
                     d->impl->grabKey(key, true);
                 }
             }

If I comment out the Q_ASSERT kded4 loads fine and the global shortcuts work.

If I load the global shortcuts after kded4 is already loaded everything works fine.

The other option I found is removing the following entries from $KDEHOME/share/config/kglobalshortcutsrc:

[juk]
back=Media Previous,Media Previous,Previous
forward=Media Next,Media Next,&Next
forwardAlbum=Ctrl+Media Next,Ctrl+Media Next,Play Next Album
mute=Volume Mute,Volume Mute,Mute
playPause=Media Play,Media Play,Play / Pause
seekBack=Shift+Media Previous,Shift+Media Previous,Seek Back
seekForward=Shift+Media Next,Shift+Media Next,Seek Forward
showHide=none,none,Show / Hide
stop=Media Stop,Media Stop,&Stop
volumeDown=Volume Down,Volume Down,Volume Down
volumeUp=Volume Up,Volume Up,Volume Up

The other bit of advice I have is that I have to manually xmodmap the media keys into xkb.  It happens on startup before KDE loads so I don't know why kded4 chokes on it.

Expected behavior: Don't crash and bring down everything else kded4 operates.

How to reproduce: In my case, go to JuK, set the global shortcuts to multimedia keys, click OK, and then kill and restart kded4.  Or better yet, logout and log back in and watch as many things don't work. :)
Comment 1 Georg Grabler 2008-05-16 11:35:13 UTC
I'm playing around with this for some time now also.
The main behaviour is, that global shortcuts are not saved when using multimedia keys (for me).
For me, kded crashes on logout - i get a short notification which gets killed later by the logout process.

Behaviour:
-> Either, go to the system settings menu / Keyboard & Mouse / Keyboard Shortcuts / JuK and configure the shortcuts using multimedia keys (in my case play/pause, raise and lower volume, as well as mute). You can also use the JuK interface directly, but due to glitches displaying the interface correctly (combobox on the bottom of the configure shortcuts dialog) i prefer the system settings variant.
-> Either keep JuK running or close it, it's not important
-> Log out and in again. You can either kill X or also do a normal logout.
-> On log-in, some keys are re assigned again:
   -> global shortcut for "up" and "down" - paging (which i usually unset)
   -> all multimedia key shortcuts are lost.
Comment 2 Andreas Pakulat 2008-06-16 21:56:47 UTC
same problem here, set kmix to use volume +/- and mute keys on my keyboard. The keys are setup properly via xkb and work fine in kde3, gnome and xfce4. Somebody really needs to fix global shortcuts or replace the code with a port of the kde3 version.

Removing all shortcuts that use multimedia keys makes the kglobalshortcuts module not crash anymore. I'm re-assigning to kdeui because thats where the kded service for shortcuts lives.
Comment 3 S. Burmeister 2008-06-18 08:19:02 UTC
I get cursor up/down assigned to kmix volume, i.e. instead of navigating the history in konsole or moving the cursor in konqueror the volumen increaes/decreases.

Is that what you meant by "paging"?
Comment 4 Michael Pyne 2008-06-18 21:20:08 UTC
Burmeister: I don't know if that's what he means by paging but I also experience this behavior on every KDE startup until I go back into JuK and then restore the global shortcuts again.  Up/Down keys are tied to volume instead of acting as arrow keys in this situation, and no multimedia keys work.
Comment 5 Georg Grabler 2008-06-21 21:09:05 UTC
@Michael, indeed, that's part of my post.

It's not just that those are tied, it's also that several application shortcuts are lost at all.
Comment 6 Stefan Majewsky 2008-06-25 15:18:16 UTC
Burmeister: Same for me on openSUSE 11.0 with 4.0.83 pages. I have key codes XF86AudioRaiseVolume and XF86AudioLowerVolume assigned to KMix, but after logon, these actions are assigned to key codes Up and Down (the arrow keys). This binding vanishes when I launch `kcmshell4 keys`. The old binding (to the multimedia keys) is not saved however.

By the way, the same occurs for XF86Standby which is the power button (which I had assigned to KRunner's shutdown action manually). This binding is not saved and restored properly.
Comment 7 Andreas Hartmetz 2008-06-26 18:10:37 UTC
Probably a long-standing Qt [QKeySequence] bug involving "exotic" keys. I'll investigate further.
Comment 8 Andreas Hartmetz 2008-07-04 12:49:46 UTC
While Qt still behaves strangely for e.g. Multimedia play/pause this has nothing to do with this particular bug - the code just didn't handle key names with spaces correctly. This has been fixed now.
Comment 9 Andreas Hartmetz 2008-07-04 12:52:18 UTC
The revision with the fix is 826892.
Comment 10 Andreas Pakulat 2008-07-05 02:00:10 UTC
I've just did some testing with kmix and juk and can confirm that as long as Qt produces reasonable keycodes for multimedia keys (which it sometimes doesn't, for example for my scrollup/scrolldown keys) the global shortcuts support works as expected.