Replies: 1 comment 1 reply
-
This is already documented in https://mpv.io/manual/master/#key-names. I have added some clarification of this behavior to documentation in #15516. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I haven't looked into how input is being handled, and I haven't tried this out on anything but my x11 system... I'm sure there's a fine reason, but this kind of hurts my brain.
results in... (key -> output)
so capital
B
and indistinguishable fromshift+B
... What if we change the ordering?results in...
Okay, so capslock acts as a shift modifier. Kinda makes sense, I guess... But that's for character keys. What about non-character keys?
results in...
So capslock acts as a shift modifier for characters, but not for non-characters.
On top of that,
shift+b
is synonymous withshift+B
, butctrl+b
is distinct fromctrl+B
, the latter implies either capslock be on orctrl+shift+b
be pressed...shift+b
can't be distinguished fromshift+B
, even if you send a lower-caseb
while holdingshift
(inverting case with capslock on)I don't really know why I'm sharing this, but I felt like it had to be mentioned somewhere in case anyone else gets confused by this behavior while troubleshooting their
input.conf
. I had always assumed that bindings were case-insensitive and that modifiers were all that was relevant; but clearly that's not the case, which is fine, but the rules are a bit unintuitive...Normally I'd like to see this sort of thing be simplified into a more coherent model, but I'm sure that would be a bad idea since there's bound to be a lot of spacebar heating
Beta Was this translation helpful? Give feedback.
All reactions