Keyboard shortcuts work correctly only when using English layout

MadFishTheOne commented 10 years ago

Shortcuts should not depend on current layout.

Layout-independent key codes can be obtained from:

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

ghost commented 9 years ago

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

eugenesvk commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 commented 8 years ago

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 commented 8 years ago

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 notifications@github.com 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 commented 8 years ago

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

divVerent commented 8 years ago

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 notifications@github.com 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 commented 7 years ago

This is still a problem

kopurando commented 7 years ago

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 commented 7 years ago

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

whoizit commented 5 years ago

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 commented 5 years ago

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

xzfc commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

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 commented 11 months ago

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 commented 8 months ago

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

aphirst commented 6 months ago

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 commented 1 month ago

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

mpv-player / mpv

Keyboard shortcuts work correctly only when using English layout #351