Problems with rebinding modifiers about klfc

[39aldo39]

This should be fixed now. modifier_map apparently doesn't find every keycode when a keysym is given.

And what do you mean by binding another key to Win? If I add [ "POS", "Win" ] to singletonKeys, it does rebind POS to Super.

[noctuid]

Both issues are fixed now. Thank you.

I don't know what the problem was before; maybe Win wasn't being recognized properly as a modifier. The error I was getting before was klfc: warning: the action ‘Win’ is not supported in XKB.

[noctuid]

I notice that if I map the position Control_L to Win, Control_L gets removed from control and added to mod4. This is not a huge problem for me, but would it be possible to not have this happen?

[39aldo39]

This is expected behavior. If you map Control_L to Win, the key Control_L becomes a Super_L modifier and shouldn't be part of control anymore and should be added to mod4. It isn't necessary that it is added to mod4 (as long as at least one Super_L is in there), but in symbols/pc there is a line modifier_map Mod4 { Super_L, Super_R };. Due to this line, xkbcomp will search for a keycode with the Super_L keysym and add it to mod4. Control_L has with the new mapping the smallest keycode with a Super_L keysym and is consequently added to mod4. That part also can't be changed, since I don't a way to remove keysyms from a modifier_map. But it isn't a problem.

This is also the reason that the line modifier_map Mod4 { <LWIN> }; is added. Since the modifier mapping from symbols/pc doesn't add <LWIN> to mod4 anymore, it should be added separately. Otherwise, <LWIN> doesn't act as a Super modifier anymore.

[noctuid]

It seems strange to me that Control_L is added instead of another Super_L; is the keycode still associated with Control_L? This does cause problems for me (e.g. any xdotool command that uses control will act as super, and Control_R needs to be used instead), but it's easy to fix by manually removing Control_L and re-adding it to control, so it is not a significant issue for me.

[39aldo39]

If I run xmodmap before the assignment, I get:

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)

After adding [ "Control_L", "Win" ] to singletonKeys, I get:

shift       Shift_L (0x32),  Shift_R (0x3e)
lock        Caps_Lock (0x42)
control     Control_R (0x69)
mod1        Alt_L (0x40),  Alt_R (0x6c),  Meta_L (0xcd)
mod2        Num_Lock (0x4d)
mod3      
mod4        Super_L (0x25),  Super_L (0x85),  Super_R (0x86),  Super_L (0xce),  Hyper_L (0xcf)
mod5        ISO_Level3_Shift (0x5c),  Mode_switch (0xcb)

So, there Control_L (0x25) is removed from control and Super_L (0x25) is added to mod4. 0x25 is the scancode of the left control key, so that is expected. Do you get Control_L (0x25) added to mod4 instead of Super_L (0x25)?

[noctuid]

My bad, the reason Control_L ends up in mod4 is that I also have [ "Win_L", "Control" ].

[39aldo39]

In that case Control_L indeed ends up in mod4. I took the case into account, but I forgot to also check for singletonKeys. It should be fixed now.

[noctuid]

Sorry for the confusion. Thanks for the quick fix.