Ctrl key bindings doesn't work from cmd.exe command line #3625

Closed
garoto opened this Issue Oct 4, 2016 · 8 comments

Projects

None yet

3 participants

@garoto
garoto commented Oct 4, 2016 edited

mpv version and platform

OS Name: Microsoft Windows Embedded 8.1 Industry Enterprise
OS Version: 6.3.9600 N/A Build 9600

cplayer: mpv 0.20.0-git-c226bc7 (C) 2000-2016 mpv/MPlayer/mplayer2 projects
cplayer: built on Fri Aug 26 19:57:46 CEST 2016
cplayer: ffmpeg library versions:
cplayer: libavutil 55.29.100
cplayer: libavcodec 57.54.100
cplayer: libavformat 57.48.100
cplayer: libswscale 4.1.100
cplayer: libavfilter 6.56.100
cplayer: libswresample 2.1.100
cplayer: ffmpeg version: N-81464-g5686748

Reproduction steps

Launch any media from cmd.exe command line interpreter; when trying to control the player via keybinds within the cmd.exe window, the "ctrl" part of keybinds are ignored.

Expected behavior

Ctrl keybindings should work.

Actual behavior

Ctrl keybindings doesn't work.

Log files

http://sprunge.us/YHKT

@garoto
garoto commented Oct 7, 2016

Can anyone else reproduce this behavior? Is my description of the issue confusing somehow (not a native speaker)?

@Hrxn
Hrxn commented Oct 7, 2016

You mean literally any key together with 'Ctrl'?

No, works for me..

@garoto
garoto commented Oct 7, 2016 edited

Yeah, I mean any keybindings with CTRL+<any_other_key> doesn't work when activated from CMD.exe window.

Like the snippet below from my input.conf:

Ctrl+LEFT   no-osd seek -30
Ctrl+RIGHT  no-osd seek 30 

Will simply activate the LEFT and RIGHT keybinds, which for me means no-osd seek -5 and no-osd seek 5 respectively, fully ignoring the CTRL modifier.

But, oh well, since you mention it works for you, I guess I need to troubleshoot further.

@Hrxn
Hrxn commented Oct 7, 2016

Wait...

work when activated from CMD.exe window.

So, you mean when this window has focus, and not mpv.exe?

Ok, just tested with mpv --input-test --force-window --idle, and you're right..
Ctrl-bindings don't work...

For example

[input] Key RIGHT is bound to:
[input] 1.  'seek  5' in <builtin>:1 (default)
[input] Key Ctrl+RIGHT is bound to:
[input] 1.  'no-osd sub-seek  1' in <builtin>:1 (default)

And with focus on cmd.exe

[input] Key RIGHT is bound to:
[input] 1.  'seek  5' in <builtin>:1 (default)
[input] Key RIGHT is bound to:

Second input should've been with Ctrl

But I guess it's not really an issue with mpv then, maybe a limitation of cmd.exe

@garoto
garoto commented Oct 8, 2016

Yes, I mean when the cmd.exe windows has focus. For instance, I have a YT music playlist I invoke from the command line with a --profile music argument that has a no-video conf. parameter in mpv.conf and that's when I observe this behavior. Sorry for the confusion.

But I guess it's not really an issue with mpv then, maybe a limitation of cmd.exe

Yeah, I was assuming so, but I guess I was seeking some confirmation this was the expected behavior in how cmd.exe parses input or whatever. Maybe some of the devs with more Windows experience can shed some light into the issue?

@Hrxn
Hrxn commented Oct 8, 2016 edited

If you want, you could try the results with an alternative terminal, like ConEmu or Cmder.

And yes, I definitely think this is a limitation of cmd.exe. Wouldn't be the first..

@rossy
Member
rossy commented Oct 9, 2016

Actually, I think it's possible to handle Ctrl bindings. There are definitely improvements to be made in mpv's console input handling. I'll take a look.

@rossy rossy added the ms-windows label Oct 9, 2016
@rossy
Member
rossy commented Oct 13, 2016 edited

Ok so handling Ctrl+Left/Right is definitely possible, as is handling Ctrl+. There are a lot of limitations compared to handling keystrokes in a GUI window though. Ctrl+ and Ctrl+Alt+ don't work, and in Windows 10, a lot of Ctrl shortcuts are taken by the console window itself (Ctrl+A selects all text, Ctrl+Up/Down scrolls the console window, etc.)

I'll submit a patch for this when I get home from work.

@rossy rossy added a commit to rossy/mpv that referenced this issue Oct 13, 2016
@rossy rossy terminal-win: support modifier keys in console input
Keyboard input in the console still isn't quite as flexible as it is in
the video window. Ctrl+<letter> and Ctrl+LEFT/RIGHT work, but
Ctrl+Alt+<letter> and Ctrl+<number> do not. Also, in the new Windows 10
console, a bunch of Ctrl keystrokes including Ctrl+UP/DOWN are handled
by the console window and not passed to the application.

Unlike in w32_common.c, we can't really translate keyboaard input
ourselves because the keyboard layout of the console window (in
conhost.exe) doesn't necessarily match the keyboard layout of mpv's
console input thread, however, using ToUnicode as a fallback when the
console doesn't return a unicode value could be a possible future
improvement.

Fixes #3625
049315f
@rossy rossy added a commit that closed this issue Oct 13, 2016
@rossy rossy terminal-win: support modifier keys in console input
Keyboard input in the console still isn't quite as flexible as it is in
the video window. Ctrl+<letter> and Ctrl+LEFT/RIGHT work, but
Ctrl+Alt+<letter> and Ctrl+<number> do not. Also, in the new Windows 10
console, a bunch of Ctrl keystrokes including Ctrl+UP/DOWN are handled
by the console window and not passed to the application.

Unlike in w32_common.c, we can't really translate keyboaard input
ourselves because the keyboard layout of the console window (in
conhost.exe) doesn't necessarily match the keyboard layout of mpv's
console input thread, however, using ToUnicode as a fallback when the
console doesn't return a unicode value could be a possible future
improvement.

Fixes #3625
0af8811
@rossy rossy closed this in 0af8811 Oct 13, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment