summaryrefslogtreecommitdiffstats
path: root/osdep/terminal-win.c
Commit message (Collapse)AuthorAgeFilesLines
* terminal: remove unused return valuewm42017-06-271-2/+1
|
* terminal: change license to LGPLwm42017-06-141-7/+7
| | | | | | | | | | | | | | | | 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.
* terminal-win: support modifier keys in console inputJames Ross-Gowan2016-10-141-2/+14
| | | | | | | | | | | | | | | | | 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
* terminal-win: clean up console inputJames Ross-Gowan2016-10-141-49/+33
| | | | | | | | | | | | | | | | | | | | | | 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.)
* player: make --terminal freetly settable at runtimewm42016-09-191-1/+2
| | | | | | | | | | | | | | | | | | | 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.
* win32: fix console output with raw stdio functionsJames Ross-Gowan2015-12-061-8/+7
| | | | | | | | | | | | | | | | 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.
* Various spelling fixesMarcin Kurczewski2015-06-181-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* Update license headersMarcin Kurczewski2015-04-131-5/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: only attach to the console from mpv.comJames Ross-Gowan2015-04-111-13/+37
| | | | | | | | | | | | | | | | | | | 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.
* Set thread name for debuggingwm42014-10-191-0/+2
| | | | | | | | | | 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.
* terminal-unix: move to threadwm42014-09-101-4/+0
| | | | | | | 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().
* terminal-win: minor simplificationwm42014-09-101-2/+2
| | | | Code should be equivalent.
* win32: correct SGR sequence handlingJames Ross-Gowan2014-08-241-5/+13
| | | | | | This should get colour working again on the Windows console. Fixes #1032.
* win32: correct HANDLE typeJames Ross-Gowan2014-08-241-2/+2
| | | | | The correct type is HANDLE, not HANDLE*, though this change shouldn't affect functionality.
* terminal-win: read input from a threadwm42014-08-211-27/+49
| | | | | | | | | 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.
* terminal: some cleanupswm42014-08-211-35/+13
| | | | In particular, remove all the stupid debug printfs from the win code.
* terminal-win: remove nonsensical codewm42014-08-211-9/+0
| | | | | Something about a non-working MinGW thing? Really, I don't care. It also prevents using the console API properly.
* win32: emulate some ANSI terminal escape codeswm42014-08-211-9/+75
| | | | | | | | | | | | | | 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.
* Remove the last remains of slave modewm42014-08-011-24/+1
| | | | | | | | | | | 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.
* w32: use the w32_common keymap in terminal-win tooJames Ross-Gowan2014-01-191-40/+13
|
* io/win32: move mp_attach_console to terminal-win.cMartin Herkt2014-01-161-0/+17
| | | | Why didn't I put it there from the start?
* player: redo terminal OSD and status line handlingwm42014-01-131-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* input: rework how input sources are addedwm42013-12-211-5/+22
| | | | | | | | | | | | | | 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.
* terminal: abstract terminal color handlingwm42013-12-201-5/+43
| | | | | | | | 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.
* Rename getch2....c/h to terminal....c/hwm42013-12-191-0/+194
"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.