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: #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//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//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@fb93010

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.

[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
#351 (comment)

[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
#351 (comment)

[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
#351 (comment)

[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 edbc199:

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 #351 (comment)? Is this #351 (comment) 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

[pbaykalov]

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]

Guys, seems like implay respects non-english keyboard layouts. It uses libmpv.

[aphirst]

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]

I wonder why this issue was closed. It's still relevant.