kde keyboard shortcuts can't capture ctrl/alt/shift plus forward

Bug #379826 reported by jshute
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
kdebase-workspace (Ubuntu)
Invalid
Undecided
Unassigned
xorg-server (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Binary package hint: kdebase-workspace

After installing kubuntu 9.04, go to System Settings, Keyboard & Mouse, Global Keyboard Shortcuts.
Pick an action, click custom to capture a shortcut.
If I press the extra keys on my keyboard like Forward, Back, Volume up, etc, it can capture those with those symbolic names.
But if I press control or alt or shift in combination with those keys, it just captures the key without the modifier.
Modifier keys are captured correctly for normal keys like letters.

This use to work in previous versions of kubuntu.

I was able to work around it by manually editing $HOME/.kde/share/config and putting in shortcuts like
Switch One Desktop Down=Alt+Forward,none,Switch One Desktop Down

and the Alt+Forward shortcut works correctly, so it's just a bug in the systemsettings program.

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 9.04
ExecutablePath: /usr/bin/systemsettings
NonfreeKernelModules: nvidia
Package: systemsettings 4:4.2.2-0ubuntu2
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_CA.UTF-8
 SHELL=/bin/bash
SourcePackage: kdebase-workspace
Uname: Linux 2.6.28-11-generic x86_64

Revision history for this message
jshute (jshute-gmail) wrote :
Revision history for this message
Thomas Kluyver (takluyver) wrote :

I can't replicate this--any key combination I try works perfectly. I'm using a laptop where the media keys are Function+another key (e.g. Play/Pause = Function + Home).

Revision history for this message
jshute (jshute-gmail) wrote :

I'm using a microsoft natural keyboard 4000, which has a row of extra keys along the top (including volume up/down, mute, pause), and forward/back buttons at the bottom.

These keys are captured correctly but lose the modifiers.

Here's what I see in xev for Ctrl+VolumeUp. It has the modifier state set on the KeyRelease but not on the KeyPress the first time. The second time (without releasing Ctrl), it has the state set for both KeyPress and KeyRelease. (For normal letter keys, the state is always set for both press and release.)

KeyPress event, serial 293, synthetic NO, window 0x2c00001,
    root 0x1a7, subw 0x0, time 1809658, (138,156), root:(197,495),
    state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 295, synthetic NO, window 0x2c00001,
    root 0x1a7, subw 0x0, time 1809769, (138,156), root:(197,495),
    state 0x4, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 295, synthetic NO, window 0x2c00001,
    root 0x1a7, subw 0x0, time 1811473, (138,156), root:(197,495),
    state 0x4, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 295, synthetic NO, window 0x2c00001,
    root 0x1a7, subw 0x0, time 1811569, (138,156), root:(197,495),
    state 0x4, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

If I do one Ctrl+VolumeUp outside the window, then click capture, and do it again, the shortcut is captured with the Ctrl modifier. (This doesn't work with Alt though because Alt+Click doesn't count as a click in the window manager.)

So maybe this is actually a bug in X or somewhere else about losing the modifiers. I don't know what is actually supposed to happen for key events.

Revision history for this message
Thomas Kluyver (takluyver) wrote :

Let's try filing against Xorg, see if anyone knows what's going on. I confirm that, trying the same thing on my own system, all four events show state 0x4.

Do you have another graphical environment that you could try testing this under, to see whether it's KDE specific?

Revision history for this message
jshute (jshute-gmail) wrote :

I installed fvwm and tried it there, and I see the same thing in xev (missing state modifiers on the KeyPress the first time).

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi jshute-gmail,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log (or Xorg.0.log.old) from after reproducing the issue?

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-xorglog
Changed in xorg-server (Ubuntu):
status: New → Incomplete
Revision history for this message
jshute (jshute-gmail) wrote :

Here's another data point, from reproducing it again in xev. If I have numlock on, the key state includes the 0x10 bit for all key up and key down events, except for the extra keys. So it isn't just losing ctrl/alt/shift modifiers, it seems to be losing all the state bits.

Press 'a':

KeyPress event, serial 34, synthetic NO, window 0x2a00001,
    root 0x1a7, subw 0x0, time 822087326, (132,102), root:(1449,127),
    state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2a00001,
    root 0x1a7, subw 0x0, time 822087430, (132,102), root:(1449,127),
    state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

Press 'Play' button twice (state 0 on the first KeyPress is wrong):

KeyPress event, serial 38, synthetic NO, window 0x2a00001,
    root 0x1a7, subw 0x0, time 822166959, (148,91), root:(1465,116),
    state 0x0, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2a00001,
    root 0x1a7, subw 0x0, time 822167031, (148,91), root:(1465,116),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 40, synthetic NO, window 0x2a00001,
    root 0x1a7, subw 0x0, time 822168311, (148,91), root:(1465,116),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x2a00001,
    root 0x1a7, subw 0x0, time 822168407, (148,91), root:(1465,116),
    state 0x10, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Bryce Harrington (bryce)
tags: added: kubuntu
Revision history for this message
Rich Johnson (nixternal) wrote :

I can confirm this action with a Kensington slimline keyboard. Though I can confirm this on every DE I use, KDE, GNOME, and Xfce.

If I press 'Ctrl+FastForward' all that I get is 'FastForward'. I never thought of using those keys with a modifier.

With that, this isn't a Kubuntu only issue for me at least.

Changed in kdebase-workspace (Ubuntu):
status: New → Invalid
tags: removed: kubuntu
Bryce Harrington (bryce)
tags: added: kubuntu
tags: removed: needs-xorglog
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for xorg-server (Ubuntu) because there has been no activity for 60 days.]

Changed in xorg-server (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.