After a little trivial work with gdb, I determined that the error causing xmodmap to fail is originating in build_modmap_from_modkeymap(). In particular, the check on line 257 (inpututils.c) which appears to enforce the requirement that there is only one modifier assigned to each key. Any ideas why this might fail?
- Ben On Sun, Jan 25, 2009 at 2:48 PM, Ben Gamari <[email protected]> wrote: > Strangely enough, before I login (in gdm) things seem to behave as > they should. Directly after I login though (even before my own minimal > ~/.Xmodmap has been loaded), the behavior I described earlier begins. > > - Ben > > > On Sun, Jan 25, 2009 at 11:13 AM, Ben Gamari <[email protected]> wrote: >> As it turns out, the problem seems to be my modmap. I'm not sure how >> this happened as before the upgrade things were fine, but the xserver >> seems to have gone a little crazy in assigning modifiers: >> >> xmodmap: up to 9 keys per modifier, (keycodes in parentheses): >> >> shift Shift_L (0x32), Shift_R (0x3e), Alt_L (0x40), Alt_R (0x6c), >> Supe >> r_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 >> >> Furthermore, xmodmap is unwilling to let me change the modifier setup, >> >> [1111 b...@mercury ~] $ xmodmap -e 'remove Shift = Alt_L' >> xmodmap: bad set modifier mapping. >> [1112 b...@mercury ~] $ xmodmap -e 'clear Shift' >> xmodmap: bad set modifier mapping. >> [1112 b...@mercury ~] $ xmodmap -e 'add Control = Control_L' >> xmodmap: bad set modifier mapping. >> >> Any ideas? Thanks, >> >> - Ben >> > _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
