No WinKey support on systems where WinKey maps to Super, not Meta

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run key-mon on a system where WinKey maps to Super
2. Press WinKey
3. Watch as the button image doesn't show it

Original issue reported on code.google.com by stephan....@gmail.com on 24 Dec 2010 at 12:58

[GoogleCodeExporter]

I can confirm this issue on my Debian box. In particular, "xev" reports the 
(only) Win key of my keyboard to map to "Super_R", which key-mon does not seem 
to recognize.

Original comment by fhollerweger01@qub.ac.uk on 14 Mar 2011 at 10:42

[GoogleCodeExporter]

It should be shown if you run

  key-mon --kbdfile=

Currently default us.kbd does not have entry for "Super_R", it's same keycode 
as "126 KEY_MULTI_KEY Multi Mul" in us.kbd. (I think it's someone's compose key 
when created this us.kbd, it should be reverted to Super_R. But I am not 
entirely sure, the keymap stuff is so ...)

If you specify no kbd file, then it will parse from `xmodmap` output then merge 
entries from `us.kbd`, which haven't been reported by `xmodmap`.

Maybe the default value (us.kbd) of options.kbd_file should be removed, so 
keymap would use the user's mapping settings?

Original comment by livibet...@gmail.com on 5 Aug 2011 at 5:41

[GoogleCodeExporter]

My view is that it's always best to pick the option which does the most to 
automatically match user settings. (Barring, of course, stuff which ties a 
program too strongly to a specific DE to justify it)

Why does it currently behave as it does? Are there regressions to worry about 
or was it just a case of thinking ahead in a way which proved to have 
unforeseen side-effects?

Original comment by stephan....@gmail.com on 5 Aug 2011 at 4:20

[GoogleCodeExporter]

I can't speak for the developer, there must be some reason to do this or that.

But did you try the command I gave above?

Original comment by livibet...@gmail.com on 5 Aug 2011 at 4:42

[GoogleCodeExporter]

I haven't had time. I reinstalled since the last time I tested key-mon and I 
just started some courses a couple of days ago, so I haven't yet settled into a 
routine with them.

I'll try to find time to test it out some time either today or tomorrow.

Original comment by stephan....@gmail.com on 5 Aug 2011 at 5:40

[GoogleCodeExporter]

I have no problem having it say "Super_R" instead of "Multi Mul", I'm sure it's 
more common. I'll make a change in the repository to reflect this.

Original comment by sc...@forusers.com on 7 Aug 2011 at 7:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Just tested it (sorry for the delay) but I'm still not sure.

`key-mon --kbdfile=` doesn't fix the problem... but somewhere along the way, my 
Logitech G15 keyboard started generating XF86Messenger (as reported by `xev`) 
rather than Super_R for the windows key.

It still works as the windows key, because the modifier mappings are set 
correctly, but I can't test Super_R.

How about just offering some kind of config option that lets me tell key-mon to 
treat Mod4 as WinKey and look up the mappings on start?

Original comment by stephan....@gmail.com on 9 Aug 2011 at 5:58

[GoogleCodeExporter]

Looks like your key map is somehow messed up.

Run
  xmodmap -e 'keycode 134=Super_R'
to remap right Win key to Super_R

then run this should work
  key-mon --kbdfile=

or
  xmodmap -e 'keycode 134=Super_L'
  key-mon

Original comment by livibet...@gmail.com on 9 Aug 2011 at 6:07

[GoogleCodeExporter]

Also please paste the output of `xmodmap`, I want to see if your
XF86Messenger is listed as mod4 or not.

Original comment by livibet...@gmail.com on 9 Aug 2011 at 6:11

[GoogleCodeExporter]

Here's the output of xmodmap before fixing it up:

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

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_L (0x25)
mod1        Alt_L (0x40),  XF86Calendar (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        XF86Messenger (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L 
(0xcf),  XF86Messenger (0xe0)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

After fixing it up, Super_L and Super_R register in key-mon with --kbdfile= and 
only Super_L registers without --kbdfile=

Original comment by stephan....@gmail.com on 9 Aug 2011 at 6:20

[GoogleCodeExporter]

Oh, forgot to mention that, as expected, fixing it up doesn't change that 
output since I was remapping keycodes, not modifiers.

Original comment by stephan....@gmail.com on 9 Aug 2011 at 6:21

[GoogleCodeExporter]

> only Super_L registers without --kbdfile=

That should work when you remap keycode 105 (0x86, the right win key) to 
Super_L. The modifier map should automatically update Super_R (0x86) -> Super_L 
(0x86)

So you don't need to use `--kbdfile=` since Super_L is already in default 
keymon kbd file.

Did you mean when you press *Right Win Key* the debug message (--debug), keymon 
only prints "Super_L" instead of "Super_R"? If so, it's expected. If you meant 
press *Right Win Key* and keymon doesn't indicate a Win Key is pressed, the I 
currently have no clue why it doesn't work.

Just out of curious, do you remap your keys? like this XF86Calendar (0xcd), or 
it's default result when you plug the keyboard? And there are TWO XF86Messenger 
on your Logitech G15 keyboard? (designed specially for IM users? XD)

Original comment by livibet...@gmail.com on 9 Aug 2011 at 6:59

[GoogleCodeExporter]

I haven't even been using --debug. (Didn't occur to me to check whether such a 
flag existed, to be honest) I've just been pressing keys and checking whether 
key-mon displays them as being pressed.

I do remap my keys. It's necessary to be able to bind the nearly two-dozen 
macro-related keys to arbitrary tasks in X11 since not all of them have symbols 
by default.

No clue why there are two XF86Messenger keysyms. All it should be used for 
under normal circumstances is making sure that all of the G1 through G18, M1 
through M3, MR, and multimedia keys as well as the buttons on my ATi Remote 
Wonder II have keysyms bound to them.

Original comment by stephan....@gmail.com on 9 Aug 2011 at 7:06

[GoogleCodeExporter]

Just to put a reference here, r43f0325c54b1, and make sure Scott could read my 
comment. (Not sure line-by-line comment will be sent to inbox)

Original comment by livibet...@gmail.com on 14 Aug 2011 at 10:41

• Changed state: Started

[GoogleCodeExporter]

This issue was closed by revision 28e19a838c00.

Original comment by livibet...@gmail.com on 25 Aug 2011 at 7:27

• Changed state: Fixed