xmodmap Oddness

William O'Higgins Witteman william.ohiggins-H217xnMUJC0sA/PxXw9srA at public.gmane.org
Wed Feb 27 16:39:49 UTC 2008


On Wed, Feb 27, 2008 at 10:38:48AM -0500, Giles Orr wrote:
>On Wed, Feb 27, 2008 at 12:22 AM, William O'Higgins Witteman
><william.ohiggins-H217xnMUJC0sA/PxXw9srA at public.gmane.org> wrote:
>>  >>  Ordinarily, I just fire up xev to get the keycode and then `xmodmap -e
>>  >>  "keycode 64 = Control_L"`.  And that has worked for all of my keys but
>>  >>  one - my Alt_L (keycode 64).  I was trying to remap it to Control_L, but
>>  >>  it is staying subbornly Alt_L.
>>  >>
>>  >>  Here's the output of xev for my uncooperative keyboard:
>>  >>
>>  >>  KeyPress event, serial 32, synthetic NO, window 0x1800001,
>>  >>     root 0x63, subw 0x1800002, time 1468606840, (37,48), root:(1538,917),
>>  >>     state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
>>  >>     XLookupString gives 0 bytes:
>>  >>     XmbLookupString gives 0 bytes:
>>  >>     XFilterEvent returns: False
>>  >>
>>  >>  KeyPress event, serial 32, synthetic NO, window 0x1800001,
>>  >>     root 0x63, subw 0x1800002, time 1468618977, (37,48), root:(1538,917),
>>  >>     state 0x10, keycode 64 (keysym 0xffe3, Control_L), same_screen YES,
>>  >>     XKeysymToKeycode returns keycode: 37
>>  >>     XLookupString gives 0 bytes:
>>  >>     XmbLookupString gives 0 bytes:
>>  >>     XFilterEvent returns: False
>>  >>
>>  >>  The top key is working as expected, but the bottom one, which is the one
>>  >>  I'd like to have actually be the Control_L, is claiming to be Control_L,
>>  >>  as I remapped it, but when I press it is still actually Alt_L.  The only
>>  >>  difference I see is that the one that doesn't do what I'd like has a
>>  >>  keysym remap.  Given I put it there, that's not a huge surprise, but I
>>  >>  am not sure what I should do.
>>  >
>>  >I was struggling with keymapping recently, sounds like a fairly
>>  >similar problem.  I was trying to get Alt_R - which by default is
>>  >mapped to AltGr, which I have no use for - to behave in the same way
>>  >as Alt_L.  I tried this:
>>  >
>>  >   xmodmap -e "keycode 113 = Alt_R"
>>  >
>>  >Good start, associating the keycode with a name.  As you did, I got
>>  >the keycode from xev.  Next:
>>  >
>>  >   xmodmap -e "add Mod1 = Alt_R"
>>  >
>>  >I thought that would do it, but it didn't because Alt_R was still
>>  >associated with Mod5 _as well as_ Mod1.  This is where I really needed
>>  >"xmodmap" without params to see what was going on - and why a keypress
>>  >wasn't giving the response I expected.  So to finish it:
>>  >
>>  >   xmodmap -e "remove Mod5 = Alt_R"
>>  >
>>  >Hope this helps.
>>
>>  I think it starts me on my way, the problem I am having is that I don't
>>  know what to call some of these keys - which ones are Mod1, Mod2, etc.
>>  Is there a way to find that out?  Thanks.
>
>I'm afraid that this is the blind leading the blind as I'm most
>assuredly not an expert ...  But try running just "xmodmap" without
>parameters.  I get an output like this:
>
>   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_R (0x71),  Meta_L (0x9c)
>   mod2        Num_Lock (0x4d)
>   mod3
>   mod4        Super_L (0x7f),  Hyper_L (0x80)
>   mod5        Mode_switch (0x5d),  ISO_Level3_Shift (0x7c)
>
>Is that what you're looking for, or will it help?

This may help.  I also found that `xmodmap -pke` returns the full key
map in the form of expressions suitable for passage to `xmodmap -e`
commands.  I'll work through that when I get home and report back.
-- 

yours,

William

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://gtalug.org/pipermail/legacy/attachments/20080227/a43f7aae/attachment.sig>


More information about the Legacy mailing list