You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Keyboard shortcuts work correctly only when using English layout #351
Wouldn't that be confusing? Also, I generally use US layout even on i.e. Italian keyboards at work (because companies buy PCs for the masses), wouldn't this feature troll me in that scenario?
This is mostly for non-latin layouts. Specifically Russian in my case. With such layouts, necessary letters are nowhere to be found. This is unlike Italian, that uses the same letters (maybe just in different places).
Since guessing whether layout is latin or not is not practical, I would suggest a user option for this.
Also on Cocoa layout switching for some reason does not work when keyboard focus is in mpv. So it is triple-pain: switch away, switch layout, switch back.
I've read through discussion, but I don't agree with the conclusion:
it's not generally possible to be independent of keyboard layout, no matter what you do it will always cuse inconveniences in one way or another.
It is definitely possible, as SDL (or any other similar library) does that exact thing for games. In fact it provides both layout-independent code and layout-dependent one AFAIK. I would recommend checking the code there for specifics.
For mpv, I would recommend a user option switch. So that both latin keyboard users with non-English-weird-key-positions, and non-latin users (I am only aware of Cyrillic) can be happy.
As an obviously highly biased Neo user I agree. I’m always pleased when games and programs manage to cope with my layout.
But: In (well written) games and other applications you generally assign actions to positions on the keyboard, what would be a non confusing way to do this in a config file? Letter → position of it on the US layout → letter on the corresponding position of your layout is kinda dumb. And really confusing. Not nearly as confusing as having to type scancodes though. Some kind of layout switching script could work though, convert all hotkeys to the active layout or something. I’m pretty sure some program (a tiling WM?) does this, I just can’t remember which one…
It already does: --input-conf=yourcyrillicinput.conf
You miss (entirely) the point of this issue. Imagine the situation: two keyboard layouts on the system - English and Russian, and user switches between them. In current situation no matter what bindings you specify, one of the layouts won't work. And that is frustrating.
Reacted by soredake, Shinkir0, snjågloe and Karol Łacina
These scancodes are not portable and you'd need huge lookup tables.
They are portable to the extent we should care about (they will work on any PC with a keyboard). For implementation specifics, check SDL (or others) - they should have figured portability already, and SDL is widely used.
And in the end you'd bother everyone with weird crap like the 'Z' binding actually mapping to the 'Y' key on German keyboard. Everyone would have trouble finding the correct symbol to bind.
That's why I recommended it to be a user option. To not bother people with weird crap.
I don't see how that's an advantage.
Advantage is for multi-layout users, that would like the same key to trigger shortcut regardless of what layout was current at the moment.
Getting layout-independent mappings is only a potential problem on X11 ("mechanism, not policy" yay! where the most common case is handled as the special case). Both OS X and Windows are more defined in that regard and getting it to work there is rather trivial.
Most other software has layout-independent bindings. Ctrl+C Ctrl+V works everywhere regardless of layout.
Useful (for some people) feature is not necessarily bloat.
Besides, this:
Just use a program that switches the keyboard layout based on the currently focused application window.
forces user to a specific workflow (per-window layout) which might not necessarily be what the user wants (in fact I prefer global layout).
workaround with mapping isn't working as it should, because the special characters are in other places.
It is simple on_mpv_window_focus to set the EN layout and save the previous window's layout, then, when the focus changes, restore the previous state of the layout. This is works for me on i3-wm very well.
Is there anyway to script keyboard layout change after launching MPV? That would be most convenient way to deal with it at least for Windows which has keyboard layout state for each program (basically).
I know this issue is closed, but I'm experiencing the same issue. I'm currently on WIndows 10 with mpv 0.37.0 and I use this machine with a Japanese keyboard and the microsoft Japanese IME. Other than the spacebar, mpv ignores keyboard inputs unless I manually switch the Language Bar from JP to EN, then it seems to work. In fact, usually I don't even HAVE any other keyboards set up since I have a JP board and no other software seems to complain about its romaji/latin input mode. What's the status of this?
Update: could be a false alarm - I reset my keyboard settings, enabled one IME input for Japanese and "Japanese (QWERTY)" for English, and now the mpv inputs register even when the Japanese IME is the active language.
Activity
pigoz commentedon Nov 20, 2013
Wouldn't that be confusing? Also, I generally use US layout even on i.e. Italian keyboards at work (because companies buy PCs for the masses), wouldn't this feature troll me in that scenario?
Nikoli commentedon Nov 20, 2013
In most GUI software keyboard shortcuts do not depend on layout, switching layout for using player is annoying. Please add this feature.
MadFishTheOne commentedon Nov 20, 2013
This is mostly for non-latin layouts. Specifically Russian in my case. With such layouts, necessary letters are nowhere to be found. This is unlike Italian, that uses the same letters (maybe just in different places).
Since guessing whether layout is latin or not is not practical, I would suggest a user option for this.
Also on Cocoa layout switching for some reason does not work when keyboard focus is in mpv. So it is triple-pain: switch away, switch layout, switch back.
MadFishTheOne commentedon Nov 20, 2013
I've read through discussion, but I don't agree with the conclusion:
It is definitely possible, as SDL (or any other similar library) does that exact thing for games. In fact it provides both layout-independent code and layout-dependent one AFAIK. I would recommend checking the code there for specifics.
For mpv, I would recommend a user option switch. So that both latin keyboard users with non-English-weird-key-positions, and non-latin users (I am only aware of Cyrillic) can be happy.
Zehkul commentedon Nov 20, 2013
As an obviously highly biased Neo user I agree. I’m always pleased when games and programs manage to cope with my layout.
But: In (well written) games and other applications you generally assign actions to positions on the keyboard, what would be a non confusing way to do this in a config file? Letter → position of it on the US layout → letter on the corresponding position of your layout is kinda dumb. And really confusing. Not nearly as confusing as having to type scancodes though. Some kind of layout switching script could work though, convert all hotkeys to the active layout or something. I’m pretty sure some program (a tiling WM?) does this, I just can’t remember which one…
MadFishTheOne commentedon Nov 20, 2013
You miss (entirely) the point of this issue. Imagine the situation: two keyboard layouts on the system - English and Russian, and user switches between them. In current situation no matter what bindings you specify, one of the layouts won't work. And that is frustrating.
MadFishTheOne commentedon Nov 20, 2013
They are portable to the extent we should care about (they will work on any PC with a keyboard). For implementation specifics, check SDL (or others) - they should have figured portability already, and SDL is widely used.
That's why I recommended it to be a user option. To not bother people with weird crap.
Advantage is for multi-layout users, that would like the same key to trigger shortcut regardless of what layout was current at the moment.
MadFishTheOne commentedon Nov 21, 2013
Few more points for completeness:
Besides, this:
forces user to a specific workflow (per-window layout) which might not necessarily be what the user wants (in fact I prefer global layout).
60 remaining items
whoizit commentedon Jun 19, 2020
workaround with mapping isn't working as it should, because the special characters are in other places.
It is simple on_mpv_window_focus to set the EN layout and save the previous window's layout, then, when the focus changes, restore the previous state of the layout. This is works for me on i3-wm very well.
https://gist.github.com/whoizit/ee6fe17673bae63f17cbdca5c611e9c0
pbaykalov commentedon Oct 11, 2023
Is there anyway to script keyboard layout change after launching MPV? That would be most convenient way to deal with it at least for Windows which has keyboard layout state for each program (basically).
whoizit commentedon Dec 16, 2023
Guys, seems like implay respects non-english keyboard layouts. It uses libmpv.
aphirst commentedon Feb 23, 2024
I know this issue is closed, but I'm experiencing the same issue. I'm currently on WIndows 10 with mpv 0.37.0 and I use this machine with a Japanese keyboard and the microsoft Japanese IME. Other than the spacebar, mpv ignores keyboard inputs unless I manually switch the Language Bar from JP to EN, then it seems to work. In fact, usually I don't even HAVE any other keyboards set up since I have a JP board and no other software seems to complain about its romaji/latin input mode. What's the status of this?Update: could be a false alarm - I reset my keyboard settings, enabled one IME input for Japanese and "Japanese (QWERTY)" for English, and now the mpv inputs register even when the Japanese IME is the active language.
birdie-github commentedon Aug 7, 2024
I wonder why this issue was closed. It's still relevant.
nobef commentedon Dec 23, 2024
Combinations do not work in this script webm.lua
JJRcop commentedon May 27, 2025
It was closed as wontfix
input/w32: add --input-layout-independent option
input/w32: add --input-layout-independent option
input/w32: add --input-layout-independent option
input/w32: add --input-layout-independent option
input/w32: add --input-layout-independent option
input/w32: add --input-layout-independent option
input/w32: add --input-layout-independent option