The attached patch fixes xmodmap for me - does it work for you?
-alan-
Alan Coopersmith wrote:
> That should only clear the lock modifier - and does so for me on Xorg 1.6.3 on
> OpenSolaris, but on Xorg master I see the same behaviour you do, with the
> other
> modifiers remapped down to the first three. Looks like a bug introduced
> since
> the Xorg 1.6 branch - probably in core server, since I'm using kbd driver and
> assume you're using evdev.
>
> -alan-
>
> Sergei Trofimovich wrote:
>> Tried to rebind CapsLock to Mod3 modifier.
>> Gentoo
>> amd64
>> Xorg master
>>
>> After issuing
>> $ xmodmap -e 'clear lock'
>> all modifiers go weird and stop working correctly.
>> I tried to paste this to file and give it ot xmodmap - the same effect, as
>> in [1]
>> !
>> ! - map capslock to meta key
>> !
>> remove Lock = Caps_Lock
>> add Mod3 = Caps_Lock
>>
>> Am I doing something grong?
>>
>> Thanks!
>> [1]:
>> $ xmodmap -pm
>> xmodmap: up to 4 keys per modifier, (keycodes in parentheses):
>>
>> shift Shift_L (0x32), Shift_R (0x3e)
>> lock Caps_Lock (0x42)
>> control Control_L (0x25), Control_R (0x69)
>> mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
>> mod2 Num_Lock (0x4d)
>> mod3
>> mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
>> mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)
>>
>> $ xmodmap -e 'clear lock'
>> $ xmodmap -pm
>> xmodmap: up to 9 keys per modifier, (keycodes in parentheses):
>>
>> shift Shift_L (0x32), Shift_R (0x3e), Alt_L (0x40), Alt_R (0x6c),
>> Super_L (0x85), Super_R (0x86), Meta_L (0xcd), Super_L (0xce), Hyper_L
>> (0xcf)
>> lock Control_L (0x25), Alt_L (0x40), ISO_Level3_Shift (0x5c),
>> Control_R (0x69), Alt_R (0x6c), Mode_switch (0xcb), Meta_L (0xcd)
>> control Num_Lock (0x4d), ISO_Level3_Shift (0x5c), Super_L (0x85),
>> Super_R (0x86), Mode_switch (0xcb), Super_L (0xce), Hyper_L (0xcf)
>> mod1
>> mod2
>> mod3
>> mod4
>> mod5
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> xorg-devel mailing list
>> [email protected]
>> http://lists.x.org/mailman/listinfo/xorg-devel
>
--
-Alan Coopersmith- [email protected]
Sun Microsystems, Inc. - X Window System Engineering
>From aad2f2e9858595cf15b1b7c4b41882f44153e3cd Mon Sep 17 00:00:00 2001
From: Alan Coopersmith <[email protected]>
Date: Mon, 3 Aug 2009 18:52:04 -0700
Subject: [PATCH] Correct modifier map built when ProcSetModifierMapping is
called
Fixes xmodmap changes to modifiers to stop corrupting modifier maps
Previous code had two bugs:
- the code to increment mod was after the code to continue if no
modifier was set, so mod wouldn't be incremented for modifiers
with no keys mapped to them (such as if you called
xmodmap -e 'clear Lock')
- the value it set in the modifier map was the raw modifier number,
not the bitmask value for that modifier
Signed-off-by: Alan Coopersmith <[email protected]>
---
dix/inpututils.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/dix/inpututils.c b/dix/inpututils.c
index 378deb0..66936c9 100644
--- a/dix/inpututils.c
+++ b/dix/inpututils.c
@@ -227,7 +227,7 @@ do_modmap_change(ClientPtr client, DeviceIntPtr dev, CARD8
*modmap)
static int build_modmap_from_modkeymap(CARD8 *modmap, KeyCode *modkeymap,
int max_keys_per_mod)
{
- int i, mod = 0, len = max_keys_per_mod * 8;
+ int i, len = max_keys_per_mod * 8;
memset(modmap, 0, MAP_LENGTH);
@@ -241,9 +241,7 @@ static int build_modmap_from_modkeymap(CARD8 *modmap,
KeyCode *modkeymap,
if (modmap[modkeymap[i]])
return BadValue;
- if (!(i % max_keys_per_mod))
- mod++;
- modmap[modkeymap[i]] = mod;
+ modmap[modkeymap[i]] = 1 << (i / max_keys_per_mod);
}
return Success;
--
1.5.6.5
_______________________________________________
xorg-devel mailing list
[email protected]
http://lists.x.org/mailman/listinfo/xorg-devel
