Commit Graph

25 Commits

Author SHA1 Message Date
wm4 dd87ce6f4b terminal: remove unused return value 2017-06-27 18:08:56 +02:00
wm4 5b3ca8ed41 terminal: change license to LGPL
All authors of the current code have agreed.

The code probably originates from a software named GySmail (as the
copyright header indicates). As far as I can tell, it was written by
Arpi (who has agreed), possibly with unknown co-authors. This is most
likely OK, as none of the original code is around anymore anyway. I
could not find a working download of GySmail, that actually contained
the original getch2.c code.

This also has a wild history of random people adding ifdef guards to
control ioctl() vs. tcgetattr() calls. (See for example 2b1310abba4c1.)
Later, the ioctl() was removed in favor of the POSIX tcgetattr(), and
the ifdeffery was removed. So these people were not contacted.
2017-06-14 14:28:05 +02:00
James Ross-Gowan 0af8811b15 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
2016-10-14 08:44:33 +11:00
James Ross-Gowan 6a8d1cdd49 terminal-win: clean up console input
The original version of this code in getch2-win.c fetched 128 console
events at once. This was probably to maximize the chance of getting a
key event if there were other events in the buffer, because it returned
the value of the first key event it found and ignored all others. Since
that code was written, it has been modified to receive console input in
an event-based way using an input thread, so it is probably not
necessary to fetch so many events at once any more. Also, I'm not sure
what it would have done if there were more than 128 events in the
console input buffer. It's possible that fetching multiple events at a
time also had performance advantages, but I can't find any other
programs that do this. Even libuv just fetches one console event at a
time.

Change read_input() to fetch only one event at a time and to consume all
available events before returning to WaitForMultipleObjects. Also remove
some outdated comments and pass the console handle through to the input
thread instead of calling GetStdHandle multiple times (I think this is
theoretically more correct because it is possible for the handles
returned by GetStdHandle to be changed by other threads.)
2016-10-14 08:44:33 +11:00
wm4 b62634c051 player: make --terminal freetly settable at runtime
So client API users don't have to care about whether to set this before
or after mpv_initialize().

We still don't enable terminal at any point before mpv_initialize(),
because reasons.

This also subtly changes some behavior how terminal options are applied
while parsing. This essentially reverts the behavior as it was reported
in issue #2588. Originally, I was hoping to get rid of the pre-parse
option pass, but it seems this is absolutely not possible due to the way
config and command line parsing are entangled. Command line options take
priority over configfile options, so they have to be applied later - but
we also want to apply logging and terminal options as specified on the
command-line, but _before_ parsing the config files. It has to be this
way to see config file error messages on the terminal, or to hide them
if --no-terminal is used. libmpv considerations also factor into this.
2016-09-19 19:54:54 +02:00
James Ross-Gowan 30bbcd6452 win32: fix console output with raw stdio functions
reopen_console_handle() was never properly tested because mpv overrides
printf in most source files. Turns out that when there's no console on
startup, the CRT sets the fds of stdout and stderr to -2, so the old
method of using dup2 to manipulate these fds didn't work. As far as I
can tell, the only way to give stdout and stderr valid fds is to use
freopen, so this uses freopen to set them both to the console output.
This also uses dup2 to change STDOUT_FILENO and STDERR_FILENO, so low-
level functions like isatty still work.

Note that this means fileno(stdout) != STDOUT_FILENO. I don't think this
will cause any problems.

This should fix MPV_LEAK_REPORT on the Windows console.
2015-12-06 02:37:38 +11:00
Marcin Kurczewski 797277a233 Various spelling fixes
Signed-off-by: wm4 <wm4@nowhere>
2015-06-18 19:36:58 +02:00
Marcin Kurczewski f43017bfe9 Update license headers
Signed-off-by: wm4 <wm4@nowhere>
2015-04-13 12:10:01 +02:00
James Ross-Gowan 527911d2a2 win32: only attach to the console from mpv.com
Previously, mpv.exe used the --terminal option to decide whether to
attach to the parent process's console, which made it impossible to tell
whether mpv would attach to the console before the config files were
parsed. Instead, make mpv always attach to the console when launched
from the console wrapper (mpv.com) and never attach otherwise. This will
be useful for the next commit, which will use the presence of the
console to decide whether to use the pseudo-gui profile.

This change should also be an improvement in behavior. The old code
would attach to the parent process's console, regardless of whether it
was mpv.com or some other program like cmd.exe. This could be confusing,
since mpv.exe is marked as a Windows GUI program and shouldn't write
text to its parent process's console when launched directly. (See #768.)

Visual Studio does something similar with its devenv.com wrapper.
devenv.exe only attaches to the console when launched from devenv.com.
2015-04-11 14:34:33 +10:00
wm4 9ba6641879 Set thread name for debugging
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.

Since this is not portable, we check the OS variants in waf configure.
old-configure just gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
2014-10-19 23:48:40 +02:00
wm4 28fc13977e terminal-unix: move to thread
Do terminal input with a thread, instead of using the central select()
loop. This also changes some details how SIGTERM is handled.

Part of my crusade against mp_input_add_fd().
2014-09-10 00:48:12 +02:00
wm4 d0b525121a terminal-win: minor simplification
Code should be equivalent.
2014-09-10 00:48:12 +02:00
James Ross-Gowan ef1c6e9295 win32: correct SGR sequence handling
This should get colour working again on the Windows console.

Fixes #1032.
2014-08-24 13:23:11 +02:00
James Ross-Gowan 67c6335efc win32: correct HANDLE type
The correct type is HANDLE, not HANDLE*, though this change shouldn't
affect functionality.
2014-08-24 13:23:09 +02:00
wm4 58a9610acf terminal-win: read input from a thread
Surprisingly, WaitFor* works on console handles. We can simply run the
code for reading the console in a thread, and don't have to worry about
crazy win32 crap in the rest of the player's input code anymore.

This also fixes the issue that you couldn't unpause the player from the
terminal, because the player would stop polling for input.
2014-08-21 22:45:58 +02:00
wm4 5890e59dbc terminal: some cleanups
In particular, remove all the stupid debug printfs from the win code.
2014-08-21 22:45:58 +02:00
wm4 070c54dff4 terminal-win: remove nonsensical code
Something about a non-working MinGW thing? Really, I don't care. It
also prevents using the console API properly.
2014-08-21 22:45:58 +02:00
wm4 47b29094c3 win32: emulate some ANSI terminal escape codes
We already redirect all terminal output through our own wrappers (for
the sake of UTF-8), so we might as well use it to handle ANSI escape
codes.

This also changes behavior on UNIX: we don't retrieve some escape codes
per terminfo anymore, and just hardcode them. Every terminal should
understand them.

The advantage is that we can pretend to have a real terminal in the
normal player code, and Windows atrocities are locked away in glue
code.
2014-08-21 22:45:58 +02:00
wm4 bf5b1e9a05 Remove the last remains of slave mode
Almost nothing was left of it.

The only thing this commit actually removes is support for reading
input commands from stdin. But you can emulate this via:

 --input-file=/dev/stdin --input-terminal=no

However, this won't work on Windows. Just use a named pipe.
2014-08-01 22:57:56 +02:00
James Ross-Gowan 32c0df1b53 w32: use the w32_common keymap in terminal-win too 2014-01-19 14:42:15 +01:00
Martin Herkt 26d6eb4a8a io/win32: move mp_attach_console to terminal-win.c
Why didn't I put it there from the start?
2014-01-16 11:25:52 +01:00
wm4 6759941fca player: redo terminal OSD and status line handling
The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).

This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).

Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.

Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.

Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).

Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.

The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.

In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
2014-01-13 20:08:13 +01:00
wm4 ed71606e65 input: rework how input sources are added
Until now, there were two functions to add input sources (stuff like
stdin input, slave mode, lirc, joystick). Unify them to a single
function (mp_input_add_fd()), and make sure the associated callbacks
always have a context parameter.

Change the lirc and joystick code such that they take store their state
in a context struct (probably worthless), and use the new mp_msg
replacements (the point of this refactoring).

Additionally, get rid of the ugly USE_FD0_CMD_SELECT etc. ifdeffery in
the terminal handling code.
2013-12-21 20:50:13 +01:00
wm4 4d4b822171 terminal: abstract terminal color handling
Instead of making msg.c an ifdef hell for unix vs. windows code, move
the code to separate functions defined in terminal-unix.c/terminal-
win.c.

Drop the code that selects random colors for --msgmodule prefixes.
2013-12-20 21:07:57 +01:00
wm4 25d4ae74f1 Rename getch2....c/h to terminal....c/h
"getch2" really tells nothing about what the heck this code does. It'd
be even worse when moving the rest of terminal handling code there.
2013-12-19 21:31:27 +01:00