Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 153260 - keyboard shortcuts dialog treats windows key as Super_L
Summary: keyboard shortcuts dialog treats windows key as Super_L
Keywords:
Status: CLOSED DUPLICATE of bug 143837
Alias: None
Product: Fedora
Classification: Fedora
Component: control-center
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-04 08:37 UTC by Msquared
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-21 20:40:08 UTC


Attachments (Terms of Use)

Description Msquared 2005-04-04 08:37:45 UTC
+++ This bug was initially created as a clone of Bug #143837 +++

Description of problem:

in a deviation from old behavior, the windows key cannot be used for
modified keystrokes in the window manager's "preferences -> keyboard
shortcuts" dialog.

I used to successfully set Windows-F1 to switch to workspace 1 (etc)
but it no longer works.  'xmodmap -pm' reports that super_l is <mod4>
and so why is it being treated as a normal keystroke instead of the
modifier that it is?  

Also, I check the bottom radio button in the "preferences -> windows"
dialog (Super is also used as the movement modifier for mouse
actions)...  

This does seem to be a change from relatively recent behavior.

Version-Release number of selected component (if applicable):


Steps to Reproduce:

preferences -> windows -> check super is movement modifier
preferences -> keyboard shortcuts -> move window to workspace 1 ->
Super-F1 

Actual results:

the modified keystroke will not register.

Expected results:

I expect "<mod4>F1" instead of "Super_L" as the keybinding.

Additional info:

xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25),  Control_R (0x6d)
mod1        Alt_L (0x40),  Alt_L (0x7d),  Meta_L (0x9c)
mod2        Num_Lock (0x4d)
mod3
mod4        Super_L (0x7f),  Hyper_L (0x80)
mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)



xev windows key only:

KeyPress event, serial 29, synthetic NO, window 0x2800001,
    root 0x58, subw 0x0, time 159802320, (-7,-67), root:(782,616),
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x2800001,
    root 0x58, subw 0x0, time 159802539, (-7,-67), root:(782,616),
    state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:




Windows + F1:

KeyPress event, serial 29, synthetic NO, window 0x2800001,
    root 0x58, subw 0x0, time 159804390, (-7,-67), root:(782,616),
    state 0x0, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x2800001,
    root 0x58, subw 0x0, time 159804560, (-7,-67), root:(782,616),
    state 0x40, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x2800001,
    root 0x58, subw 0x0, time 159804654, (-7,-67), root:(782,616),
    state 0x40, keycode 67 (keysym 0xffbe, F1), same_screen YES,
    XLookupString gives 0 bytes:

KeyRelease event, serial 29, synthetic NO, window 0x2800001,
    root 0x58, subw 0x0, time 159804905, (-7,-67), root:(782,616),
    state 0x40, keycode 115 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:

Comment 1 Matthias Clasen 2005-04-21 20:40:08 UTC

*** This bug has been marked as a duplicate of 143837 ***


Note You need to log in before you can comment on or make changes to this bug.