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