Mpv: Keyboard shortcuts work correctly only when using English layout

[MadFishTheOne]

Shortcuts should not depend on current layout.

Layout-independent key codes can be obtained from:

1. event.xkey.keycode on X11.
2. [event keyCode] on Cocoa.
3. wParam on Windows.

[pigoz]

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]

In most GUI software keyboard shortcuts do not depend on layout, switching layout for using player is annoying. Please add this feature.

[ghost]

This was already discussed here: https://github.com/mpv-player/mpv/issues/45

[MadFishTheOne]

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]

This was already discussed here: #45

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.

[Zehkul]

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…

[ghost]

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.

It already does: --input-conf=yourcyrillicinput.conf

[ghost]

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…

There are programs that can switch your keyboard layout depending on what application's window is focused.

[MadFishTheOne]

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.

[ghost]

Then use a keyboard layout switcher.

These scancodes are not portable and you'd need huge lookup tables. 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. I don't see how that's an advantage.

[MadFishTheOne]

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.

[ghost]

For implementation specifics, check SDL (or others) - they should have figured portability already

Yes, and I've seen a very big bunch of dirty hacks.

That's why I recommended it to be a user option.

Making it an option would require even more code. (You'd have to keep the code for old method and the new one.)

Advantage is for multi-layout users, that would like the same key to trigger shortcut regardless of what layout was current at the moment.

Just use a program that switches the keyboard layout based on the currently focused application window. This is much simpler, saves us a lot of trouble, and avoids bloat in mpv.

[MadFishTheOne]

Few more points for completeness:

1. 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.
2. Most other software has layout-independent bindings. Ctrl+C Ctrl+V works everywhere regardless of layout.
3. 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).

[ghost]

If someone wants to implement it (in a non-intrusive enough way) I wouldn't be opposed to it. But personally I don't want to work on this. Probably nothing will happen into this direction, so I'm closing this for now.

forces user to a specific workflow (per-window layout) which might not necessarily be what the user wants (in fact I prefer global layout).

You could configure it to switch the layout for mpv, but not any other application.

[otommod]

Checkout xkb-switch !

[MadFishTheOne]

I would suggest leaving the issue open, so that people can find it.
Closing an issue means "this user story is resolved" (fixed, or would-not-fixed). However, that is not really the case here.

[ghost]

Having too many issues open is a problem for me, because I can't see which things need work and for which are resolved.

[ghost]

I can reopen it, if you take offense.

I won't work on this, though.

[divVerent]

There are three issues if we made the controls scancode-aware:

1. mpv also runs on a terminal, e.g. when playing music. And we cannot get
   scan codes there.
2. Documentation - we simply cannot describe such a mapping with text. A
   picture of a keyboard with is assignments would work, but can not be put on
   a manpage.
3. input.conf becomes a mess.

[Nikoli]

2 and 3 do not exist: input.conf will still use english letters.

[divVerent]

That IS the issue. When the doc says press Y but you have to press Z, that
is bad. In the conf it may be acceptable, in the documentation sure not.
Am 22.11.2013 21:14 schrieb "Nikoli" [email protected]:

2 and 3 do not exist: input.conf will still use english letters.

—
Reply to this email directly or view it on GitHubhttps://github.com/mpv-player/mpv/issues/351#issuecomment-29105441
.

[Nikoli]

As user i press button with both 'm' and 'ь', but software may interpret it as 'm', 'ь' or 'cycle mute', etc depending on circumstances. The idea is to make mpv layout agnostic.

[divVerent]

As end user, if the docs say press Y - why do you expect me to know that is
Z on my keyboard? Not everyone knows US layout.
Am 22.11.2013 22:04 schrieb "Nikoli" [email protected]:

As user i press button with both 'm' and 'Ø', but software may interpret
it as 'm', 'Ø' or 'cycle mute', etc depending on circumstances. The idea is
to make mpv layout agnostic.

Reply to this email directly or view it on GitHubhttps://github.com/mpv-player/mpv/issues/351#issuecomment-29109182
.

[divVerent]

Adding: the only fix I can see is a layout picture, instead of saying "the
key Y does ...".

But how to fit that in the manpage?

[ghost]

Yep, it would be very strange if the manpage says "Key Y does action A" and "Z does action B", but then the actions are apparently swapped on the keyboard. And then the user tries the terminal, and it's acting as the manpage documents. That must be pretty confusing. Maybe we'd then get feature requests demanding to reverse-map terminal input as if it used the other layout...

Anyway, I think MadFishTheOne suggested that the "layout independent" way shouldn't be default, just that there should be a switch to enable it.

And again, I don't see how that's better than creating a Russian input.conf, which had to be there _additionally_ to the English bindings to make sure it works with both keyboard layouts.

[divVerent]

As for Russian: why not just add Cyrillic bindings to our default config?
And Greek too, maybe.

Only issue: there are two common Cyrillic layouts. My wife uses the non
phonetic one; however, does it make more sense to map keys to same location
or phonetic equivalence to Russian end users?

As for reverse mapping on the terminal: forget it. Too complex due to
handling shift-digit, Ctrl and such stuff.

So I suggest: for now let's make it an option, handled by each vo event
handler back end separately.

In the future: make audio use a vo window too (then only non-window vo like
lavc, null will trigger the terminal handling). And in these operation
modes, the only key you really need is Q.

As for the manpage: one idea might be to include ascii art of US layout,
and referring to keys by the US layout names. As we would only include one
keymap diagram, we then have to be careful to e.g. write Shift-2 and not @.

BTW: on windows, editing shortcuts are NOT layout independent, as opposed
to what someone here wrote. Undo key (Ctrl-Z) e.g. moves between German and
US layout. I would rather think Windows Cyrillic layouts might send Latin
letter keys when combined with Ctrl/Alt - either that, or Windows
applications/controls define shortcuts per language (MS Word e.g. does,
German bold is Ctrl-F and not Ctrl-B despite these keys being identical
between US and German layout). Any windows developer here?

[ghost]

In the future: make audio use a vo window too (then only non-window vo like
lavc, null will trigger the terminal handling). And in these operation
modes, the only key you really need is Q.

Like with --force-window? I disagree that terminal handling doesn't matter, though. I often use the terminal controls myself, even for video.

[MadFishTheOne]

RFC patch:
MadFishTheOne/mpv@fb930105e4e52fd6be7c592533180d01f6c605c1

Adds --keyboard-layout-independent option and implements it for Cocoa.
Not sure really about that whole options passing thing. Summoning pigoz to review that part.

[pigoz]

Maybe make it an input option instead of a vo option? Like media_keys for instance. From the vo you can access the input context anyway and you could have opaque accessors for this config. Not sure what @wm4 thinks.

[MadFishTheOne]

So you mean storing the flag in input_ctx, and providing an accessor function like

bool mp_input_is_keyboard_layout_independent(const struct input_ctx *ictx);

?

Seems like a valid approach to me (less intrusive than what I did).

[pigoz]

yes, that's what I had in mind.

[MadFishTheOne]

Updated version available at:
MadFishTheOne/mpv@db52878df74486b35793be3ca30b554ae41ec525

This should be of mergeable quality now, hopefully.

[ghost]

IMO looks really ugly. The option name isn't good. This is not keyboard layout indepdendent, it's layout _dependent_, because now it depends on the physical layout of the keyboard what you get. Also, apparently it uses the US layout, so there's nothing "independent" about it.

And I _really_ wonder why this should be in a video player. We're not even a game engine.

What's with the shift table?

[MadFishTheOne]

Basically the option means "interpret keyboard events as if they happened with English US layout, regardless of what layout you actually use". Which in turn means that your input.conf works with whatever layout without changes (as if it was specified for English US). English US is picked as a sensible default one. That is the layout most people with this issue would use to input English letters.

I don't care much about how the option is named, so why not suggest a better name?

Shift table is needed, because, for example, keybindings for 3 and # are different things.

[ghost]

So I heard OSX has native per-application keyboard layouts or similar. This option should be explored first. E.g. is there a mechanism to make OSX always use US keyboard layout for mpv? Or if not, can mpv request this layout? This would be much better than stupid hardcoded tables.

I don't care much about how the option is named, so why not suggest a better name?

Maybe force-us-keyboard-layout or something.

Shift table is needed, because, for example, keybindings for 3 and # are different things.

What about bindings with Alt or Ctrl?

[pigoz]

So I heard OSX has native per-application keyboard layouts or similar. This option should be explored first. E.g. is there a mechanism to make OSX always use US keyboard layout for mpv? Or if not, can mpv request this layout? This would be much better than stupid hardcoded tables.

Apparently it is per-document. mpv is not document based though. Maybe there is some way to get this to work correctly in mpv though.

[MadFishTheOne]

What about bindings with Alt or Ctrl?

Keyboard modifiers are still passed through, just as before (did you even look at the code? _sigh_). Shift is handled specially only because we actually specify bindings like #, and not Shift+3. That's why there is a translation table to know what symbol is Shift+3.

Maybe force-us-keyboard-layout or something.

keyboard-layout-indepedent was stating the intention, and force-us-keyboard-layout is stating the implementation detail. I would say that intention is more important, but this is all bikeshedding, so whatever. As I said before, I don't care much.

So I heard OSX has native per-application keyboard layouts or similar.

Unless there is an API for an application to declare desired keyboard layout (which I doubt there is), this is still a workaround territory, and does not truly solve the issue.

[divVerent]

I think the point is rather that we see the current behavior as layout
independent and the suggested one as layout dependent.

Because: if the manpage says Y and the user has to first map that to US
layout to know which key is actually meant, this mapping depends on the
user's layout - e.g. a German user has to press Z when the manpage would
say Y. It makes sense to call THAT layout dependent.

That is why I oppose both namings "layout dependent" and "layout
independent" - both interpretations make sense and thus it's a bad option
name if it means one thing to some users and the exact opposite to others.

[ghost]

What's the status on this? Not that I want it in.

[MadFishTheOne]

I was under impression that the status was precisely that "you don't want it in". Hence technical discussion ceased as pointless.

If you've changed your mind, patch is still there. And you can change option name to whatever you like (as that seems to be the only actual objection).

[ghost]

I was under impression that the status was precisely that "you don't want it in".

I'm against it, but if there are enough people who want it, you can get it in.

[Jessidhia]

A possible workaround I was considering is to have a script in TOOLS that a user can run to translate the input.conf between different keyboard layouts; that way, you could have an input.conf that had the keys in their intended positions (such as 'z' and 'x' for subtitle delay actually being together in the lower left of the keyboard), or an input.conf that actually works at all on non-latin keyboards.

This, of course, doesn't solve the issue that would be fixed by using hardware scancodes, but that is a different can of worms (such as what "layout-dependent" means as pointed out by @divVerent).

[ghost]

Here's another idea I just had: add a translation table of unicode characters, so if you press a key, and it produces a character mapped by it, then use the translated character to look up input.conf.

Should make the russians happy and doesn't require anything special in the backend input code.

[Jessidhia]

The problem with that is that there are 2 commonly used russian layouts (phonetic and standard) and they're completely different between themselves...

[Nikoli]

The problem with that is that there are 2 commonly used russian layouts

What do you mean? Only qwerty/йцукен is commonly used, it is very hard aka almost impossible to buy device with non йцукен layout.

[Jessidhia]

I was thinking of QWERTY layouts that wrote the "phonetic equivalent" cyrillic letter (e.g. "T" in QWERTY would write "т" in cyrillic), but I guess that such layouts are more used by non-native speakers than actual russians.

[ghost]

So if there's only 1 common layout, would my suggestion work or not?

Here's another idea I just had: add a translation table of unicode characters, so if you press a key, and it produces a character mapped by it, then use the translated character to look up input.conf.

[Nikoli]

It should work. I did not check, but isn't such table already provided by X11, input drivers or some other low level software?

[ghost]

So, can anyone make such a table? Then I can implement it. Something like a text file with the cyrillic character in the first column, and the ASCII one in the second column (according to the keyboard layout).

but isn't such table already provided by X11, input drivers or some other low level software?

Probably, but I expect it to be nearly inaccessible, or only accessible with a lot of pain.

[Nikoli]

May be this will help:
https://qt.gitorious.org/qt/qt/source/0c03af0d4d928bdbb32b09eedb1dba3ce59e5278:src/gui/kernel/qkeymapper_x11.cpp

https://bugreports.qt-project.org/browse/QTBUG-32908

[ghost]

Nobody has additionally complained for over a year, so no need to put more energy into this.

[eugenesvk]

Would my complaint allow this issue to be reopen and resolved? Especially given that there is a proposed patch by @MadFishTheOne (not sure how relevant it is).
It is annoying that if I switch layouts I'm no longer able to control the behavior of the app, especially given that it's a non-issue for all other apps (I think it's the OSX document-based option that was referenced).
Not sure why you're so much against with this request — I hope you can appreciate the user's inconvenience when there is only one app that breaks the expected behavior.

[ghost]

Not sure why you're so much against with this request

Because most of the outlined solutions would fundamentally complicate input handling _and_ user configuration?

[eugenesvk]

How does it complicate user configuration if only users who want this feature would enable it with --keyboard-layout-independent? Everyone else can safely ignore it if they don't have alternative layouts.

Re. input handling complications not sure what you mean since this thread doesn't contain any specific argument against MadFishTheOne's patch, only some rather tangential discussions on what the flag name should be (here is another idea --force-US-layout). And the code with two structs for keyboard mappings doesn't seem overly complex.

[ghost]

How does it complicate user configuration

Because it's weird and hard to explain. Users would complain that it doesn't work in any intuitive way, and then complain that it's not "fixed".

not sure what you mean since this thread doesn't contain any specific argument against MadFishTheOne's patch,

It requires a huge lookup table, and his patch even duplicates it for combination with shift. The patch is also OSX-specific and every platform would need its own code for it.

[divVerent]

In fact, X11 provides no such lookup facility (X11's lowest "public" layer
are keysyms, which have some mapping already applied), and what about
terminal input (for audio files)? Having different keybinds between xterm
and mpv windows seems worse than a suboptimal key assignment. Also, as a
precedent, SDL on X11 also maps keysyms and not "scancodes" (i.e. y/z are
"swapped" on German layout), despite being a low level game programming
library. If even SDL can't provide a proper layout independent key matching
on X11, that's a pretty strong sign that it's impossible (instead, SDL IIRC
provides a /dev/input based way achieving that, though).

Anyway, is there an X11 or at least freedesktop way for per-window keyboard
layouts like on Windows? That may be a lot cleaner in the end.

On Wed, Apr 6, 2016, 15:08 V. Lang [email protected] wrote:

How does it complicate user configuration

Because it's weird and hard to explain. Users would complain that it
doesn't work in any intuitive way, and then complain that it's not "fixed".

not sure what you mean since this thread doesn't contain any specific
argument against MadFishTheOne's patch,

It requires a huge lookup table, and his patch even duplicates it for
combination with shift. The patch is also OSX-specific and every platform
would need its own code for it.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/mpv-player/mpv/issues/351#issuecomment-206516683

[eugenesvk]

Because it's weird and hard to explain.

It's not hard to explain: (with this option) any key press is recognized as though you had US English layout active even when your current layout is different.
Example: if German layout is currently active, pressing y (bottom-left button) will be read as US English z just like when US English layout is active.

Users would complain that it doesn't work in any intuitive way, and then complain that it's not "fixed"

Users don't even need to know how it works as long as it does.

huge lookup table

~40 elements is a huge table? Hm, ok.

every platform would need its own code for

If it bothers you, just leave only OSX version since there is already a patch for it and you don't have to add any code by yourself. And if someone else prepares a patch for another OS.

[divVerent]

The platform where this is most complicated is X11. Incidentally the
platform most mpv developers are using...

is Wayland any better there?

On Wed, Apr 6, 2016, 16:36 Evgeny [email protected] wrote:

Because it's weird and hard to explain.

It's not hard to explain: (with this option) any key press is recognized
as though you had US English layout active even when your current layout is
different.
Example: if German layout is currently active, pressing y (bottom-left
button) will be read as US English z just like when US English layout is
active.

Users would complain that it doesn't work in any intuitive way, and then
complain that it's not "fixed"

Users don't even need to know how it works as long as it does.

huge lookup table

~40 elements is a huge table? Hm, ok.

every platform would need its own code for

If it bothers you, just leave only OSX version since there is already a
patch for it and you don't have to add any code by yourself. And if someone
else prepares a patch for another OS.

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/mpv-player/mpv/issues/351#issuecomment-206552876

[ghost]

Wayland just uses libxkb. (Which we could also do under X btw. The core input we're using is basically ancient crap.)

[divVerent]

libxkbcommon could indeed help - it'd reduce the platform dependent stuff
we need for this feature to the xkb name of the US layout. Which on all
systems I know is just "us". We'd still need to work with core X11 events,
but yes, this could be a good replacement for the mapping to characters.

On Wed, Apr 6, 2016, 16:58 V. Lang [email protected] wrote:

Wayland just uses libxkb. (Which we could also do under X btw. The core
input we're using is basically ancient crap.)

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
https://github.com/mpv-player/mpv/issues/351#issuecomment-206565029

[whoizit]

This is still a problem

[kopurando]

Folks,
It's a valid problem in MANY apps, not just mpv,
Thankfully, mpv offers a solution to those who bothered by it,
just modify your input.conf:

Q quit_watch_later
Й quit_watch_later
й quit
х multiply speed 0.9091                # scale playback speed
ъ multiply speed 1.1
< multiply speed 0.995                # scale playback speed
> multiply speed 1.005
a cycle audio
ф cycle audio

etc.

This issue is very useful though, as other apps' devs can be referred here for their own version of this problem analysis and potential solutions.

Thanks to all who contributing to the project!

[whoizit]

my workaround https://github.com/whoizit/mpv-351-workaround
looks like works for me.

[whoizit]

we still have this annoying issue with this in 2019 year

you do not need to change input.conf, you need to interpret the English letters in input.conf as keycodes in mpv. There is no difference in the keycodes for the English, Russian, Italian, Franch, Germany, Finnish layouts, I tested. This is all the same codes 0-255, in the same places, "1" on the English layout means keycode 10, as well as in any others layouts.

Letters and numbers and special characters, all have the same keycode on the keyboard, on different layouts. I only test in on xorg with xev tool. I guess same on Wayland.

So we can press any key on any layout and it will be have same keycode. Why not using it in mpv? I don't know C or C++. I rly hard to understand how it works inside mpv and make a patch. But I belive u can do it eazily. Seems like it's a simple issue for main developer.

the whole world suffers because you have a single layout and don't understand all the pain as it is inconvenient and annoying to constantly switch to English layout every time.

again, keycodes absolutely the same, why not load English latters in input.conf and operate with it as keycodes in mpv?

[whoizit]

https://gist.github.com/whoizit/ee6fe17673bae63f17cbdca5c611e9c0

[xzfc]

GTK apps handle this issue correctly, and I don't see the reason why mpv on X11 cannot be the same.

Here is simple workaround patch for current master edbc1999145b5593098f09042947bf1b79323d2e:

diff --git a/video/out/x11_common.c b/video/out/x11_common.c
index 467fa827ac..95ca38e598 100644
--- a/video/out/x11_common.c
+++ b/video/out/x11_common.c
@@ -1080,6 +1080,11 @@ void vo_x11_check_events(struct vo *vo)
             int modifiers = get_mods(Event.xkey.state);
             if (x11->no_autorepeat)
                 modifiers |= MP_KEY_STATE_DOWN;
+           keySym = XLookupKeysym(&Event.xkey, 0);
+           int mpkey = vo_x11_lookupkey(keySym);
+           if (mpkey)
+                   mp_input_put_key(x11->input_ctx, mpkey | modifiers);
+           break;
             if (x11->xic) {
                 Status status;
                 int len = Xutf8LookupString(x11->xic, &Event.xkey, buf,

• Still handles non-us layout (setxkbmap fr, etc).
• New: mpv now quits when й is pressed (setxkbmap us,ru). This is what this issue is about.
  Note this is not tied to a particular layout, so the following cases are handled in a proper way (mpv quits):
  
  
  
  • non-us layout: ф is pressed (setxkbmap fr,ru)
  
  
  • another non-latin layout: я is pressed (setxkbmap us,ru -variant ',phonetic_winkeys')
  
  

Drawbacks:

• Keybindings not in non-primary layout no longer works (like ы quit in input.conf, or French keybindings with setxkbmap us,fr).
• It works only when latin layout is primary (setxkbmap us,ru is OK, but not setxkbmap ru,us).
• Probably lua scripts that provide textual input are broken. I haven't checked.

These drawbacks can be fixed, but I think it would require more intrusive code changes, and I am not familiar with mpv code base. The idea is to check keybinding for keysym in the current active layout first, then (if no such binding) fallback to other layouts. Or, as a first approximation, check Xutf8LookupString first, then fallback to XLookupKeysym.

---

@whoizit

There is no difference in the keycodes for the English, Russian, Italian, Franch, Germany, Finnish layouts, I tested.

No, e.g. keycode for q in French and US keyboard is different. See xev output:

us: state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
fr: state 0x0, keycode 38 (keysym 0x71, q), same_screen YES,

[ArtyomR0Bot]

It's ok, because I'm using an US layout by default.
But it bugs me. There is an easy, non-intrusive way to resolve this issue.
Let's assume there is a file like this:

Q=Й
W=Ц
# more mappings
q=й
w=ц
# more mappings

We can let user to specify such file as a keymap
--keymap="~~/keymaps/my-keymap.conf"
The way to implement this is straightforward: we need to initialize a lookup table, and just lookup a key in a table if a keymap file was specified.
Then community can add specific mappings to the github repository.

[ghost]

No. At most someone could add an option that makes the backends send "scancodes" or whatever, but as I said a few years ago, I won't implement this myself.

[ArtyomR0Bot]

@wm4 I did not assume that you should implement this function yourself. Just shared my opinion. Perhaps I will make a merge request someday if it will bother me so much.

[norstbox]

@wm4 What's about your idea https://github.com/mpv-player/mpv/issues/351#issuecomment-37338305? Is this https://github.com/mpv-player/mpv/issues/351#issuecomment-40001534 still relevant?

Workaround from @whoizit include needed mapping.

[ghost]

@norstbox hm maybe not, at least not by me. Also, the scancode idea (using raw scancodes, keysyms, or whatever in input.conf) would be the simplest and most flexible, just not most user friendly.

[whoizit]

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