Re: Bug#259740: Fw:Bug#259740: xlibs: Windows key no longer treated as modifer,just as Super_L
unmerge 259740
reopen 259740
severity 259740 normal
tags 259740 - patch
thanks
Rationale: This bugreport was merged with others; some issues are fixed,
but others like this one are still under discussion.
On Thu, Sep 09, 2004 at 08:37:00AM -0700, Scott Robinson wrote:
> -- 1
> 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)
> -- 1
>
> -- 2
>
> -- 2
> (nothing outputs from 'xkbcomp :0')
I asked you to send the generated server-0.xkb file, but Sebastien
Bacher told me on IRC how to reproduce this bug, so this is no more
necessary.
> 3. As for the altwin:meta_win, that is not what I want. I want the Windows
> key to be a modifier other than Meta. My alt key is already Meta, and that's
> just fine.
>
> If the modifier was Mod4, that would be best. If it is something else, I
> could handle that too. Right now, it appears the key is simultaneously Mod4
> and a normal keypress.
I ran
$ METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1 \
METACITY_DEBUG_BUTTON_GRABS=1 metacity
then launched
$ gnome-keybinding-properties
and changed switching between windows by trying to map this action
to Super_L+Tab (as I tried several times, it may not have the
default value).
The log file contains (my comments are prefixed by a dash sign)
Window manager: Metacity version 2.8.1 running on 09.09.2004
...
KEYBINDINGS: Binding "switch_windows" has new gconf value "Super_L"
KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xffeb mods = 0x0
# xev tells that Super_L is indeed 0xffeb, but modifiers are 0x40.
# this output means that the Super_L key is pressed without modifiers,
# so in fact it is not seen as a modifier, see <Alt>Tab below for
# another example.
...
SM: Initializing session with save file '(none)'
SM: Obtained session ID 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
Window manager: Opening display ':0.0'
KEYBINDINGS: Display has keycode range 8 to 255
KEYBINDINGS: Keysym Alt_L bound to modifier 0x8
KEYBINDINGS: Keysym Meta_L bound to modifier 0x8
KEYBINDINGS: Keysym Alt_L bound to modifier 0x8
KEYBINDINGS: Keysym Meta_L bound to modifier 0x8
KEYBINDINGS: Keysym Num_Lock bound to modifier 0x10
KEYBINDINGS: Keysym Pointer_EnableKeys bound to modifier 0x10
KEYBINDINGS: Keysym Super_L bound to modifier 0x40
# as said above, so this binding is correct here
KEYBINDINGS: Keysym Hyper_L bound to modifier 0x40
KEYBINDINGS: Keysym Mode_switch bound to modifier 0x80
KEYBINDINGS: Keysym ISO_Level3_Shift bound to modifier 0x80
KEYBINDINGS: Ignoring modmask 0x12 num lock 0x10 scroll lock 0x0 hyper 0x40 super 0x40 meta 0x8
# hey, is this message normal? are these modifiers all ignored?
KEYBINDINGS: Rebuilding window binding table from preferences
KEYBINDINGS: 11 bindings in table
KEYBINDINGS: Rebuilding screen binding table from preferences
KEYBINDINGS: Binding switch_windows also needs Shift grabbed
KEYBINDINGS: Binding switch_panels also needs Shift grabbed
KEYBINDINGS: Binding cycle_windows also needs Shift grabbed
KEYBINDINGS: Binding cycle_panels also needs Shift grabbed
KEYBINDINGS: Binding cycle_panels_backward also needs Shift grabbed
KEYBINDINGS: 19 bindings in table
KEYBINDINGS: Reloading keycodes for binding tables
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_left)
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_right)
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_up)
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_down)
KEYBINDINGS: Devirtualized mods 0x0 -> 0x0 (switch_windows)
KEYBINDINGS: Devirtualized mods 0x20 -> 0x1 (switch_windows)
...
KEYBINDINGS: Binding "switch_windows" has new gconf value "Super_L"
KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xffeb mods = 0x0
# err, maybe mods is null because this modifier was ignored?
...
# now let's define it to <Alt>Tab
KEYBINDINGS: Binding "switch_windows" has new gconf value "<Alt>Tab"
KEYBINDINGS: New keybinding for "switch_windows" is keysym = 0xff09 mods = 0x80
# okay, 0xff09 is <Tab> (see keysymdef.h), and see below why mods
# is 0x80 and not 0x8
...
KEYBINDINGS: Rebuilding screen binding table from preferences
KEYBINDINGS: Binding switch_windows also needs Shift grabbed
...
KEYBINDINGS: Reloading keycodes for binding tables
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_left)
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_right)
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_up)
KEYBINDINGS: Devirtualized mods 0xc0 -> 0xc (switch_to_workspace_down)
KEYBINDINGS: Devirtualized mods 0x80 -> 0x8 (switch_windows)
KEYBINDINGS: Devirtualized mods 0xa0 -> 0x9 (switch_windows)
# so here is how <Alt>Tab works.
To me, it looks like the line
KEYBINDINGS: Ignoring modmask 0x12 num lock 0x10 scroll lock 0x0 hyper 0x40 super 0x40 meta 0x8
is the root of this problem, ie. why Super keys do not work.
This bug was introduced by changes in xlibs, and upstream asserted that
he won't revert these changes because they are necessary for other
purposes, so we should try to help GNOME developers to see how this bug
can be fixed. I see 2 ways: either find why Super keys are ignored,
or hack GNOME keyboard selector to map modifiers to different values.
The former is the best solution, but I am unable to help here.
Are there GNOME developers who are willing to debug this issue?
Denis
Reply to: