Closed noctuid closed 7 years ago
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.
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
.
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?
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.
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.
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)
?
My bad, the reason Control_L
ends up in mod4
is that I also have [ "Win_L", "Control" ]
.
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.
Sorry for the confusion. Thanks for the quick fix.
If i try to bind win to control in the singletonKeys section (
[ "Win_L", "Control" ]
), win doesn't do anything. The same happens if I try to bind shift to control. However,[ "Shift_L", "Control_R"]
does work. Trying to bind win to any of the controls does not work though.On a somewhat related note, if I try to bind another key to
Win
, I get an error that XKB does not support rebinding it. Is that correct? It seems a little strange since xmodmap supports rebinding keys to be super.