- win32-console-wrapper.c was inconsistently using the explicit Unicode
versions of some Windows API functions and structures.
- vo.c should use llabs for int64_t, since long is 32-bit on Windows.
- vo_direct3d.c had a potential use of an uninitialized variable if it
took the first goto error_exit.
This fixes the build in mingw-w64/Clang on MSYS2. It also disables the
use of gnu_printf in Clang, which was what was causing most of the
warnings. The Clang-compiled mpv binary appears to work, but there are
no guarantees yet, since until now mpv has only been tested with
mingw-w64/GCC on Windows.
Fixes#3800
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
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.)
We always want to use __declspec(selectany) to declare GUIDs, but
manually including <initguid.h> in every file that used GUIDs was
error-prone. Since all <initguid.h> does is define INITGUID and include
<guiddef.h>, we can remove all references to <initguid.h> and just
compile with -DINITGUID to get the same effect.
Also, this partially reverts 622bcb0 by re-adding libuuid.a to the
build, since apparently some GUIDs (such as GUID_NULL) are not declared
in the source file, even when INITGUID is set.
Seems like this confused users quite often.
Instead of --profile=pseudo-gui, --player-operation-mode=pseudo-gui now
has to be used to invoke pseudo GUI mode. The old way still works, and
still behaves in the old way.
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.
Until now, the terminal thread always sent a quit command if the
terminal thread was torn down (whether it happened via terminal_uninit()
or a quit signal). This is not so good if we want to enable toggling
terminal use at runtime, since disabling the terminal would always make
the player quit. So we want terminal_uninit() not to send quit.
This can be easily fixed by using the "death byte" sent to the pipe used
for thread tear-down to indicate whether it was caused by a signal or
terminal_uninit().
This time it's emulation that's supposed to work (not just dummied out).
Unlike the previous emulation, no mpv code has to be disabled, and
everything should work (albeit possibly a bit slowly). On the other
hand, it's not possible to implement this kind of emulation without
compiler support. We use GNU statement expressions and __typeof__ in
this case.
This code is inactive if stdatomic.h is available.
Always require them, instead of just for some components which have hard
requirements on correct atomic semantics. They should be widely
available, and are supported by all recent gcc and clang compiler
versions. We even have the fallbacks builtins, which should keep this
working on very old gcc releases.
In particular, w32_common.c recently added a hard requirement on
atomics, but checking this properly in the build system would have been
messy. This commit makes sure it always works.
The fallback where weak atomic semantics are always fine is in theory
rather questionable as well.
Old-style commands using _ as separator (e.g. show_progress) were still
used in some places, including documentation and configuration files.
This commit updates all such instances to the new style (show-progress)
so that commands are easier to find in the manual.
For some reason, the lack of version info was preventing mpv from
appearing in the Default Programs dialog. Re-add it, but don't set the
string version numbers from version.h, because that's what was causing
trouble when the version info was removed. Like the binary version
numbers, these are now hardcoded to 2.0.0.0, which probably doesn't
matter.
The new version info block is also slightly different to the old one. It
fills out all the binary VERSIONINFO fields and makes better use of
macros. It also removes the \000 line terminators from the string
version info, since as far as I can tell, this was just cargo-culting
for an old broken version of the Microsoft resource compiler, and
binutils' windres terminates the strings properly without them.
For clang, it's enough to just put (void) around usages we are
intentionally ignoring the result of.
Since GCC does not seem to want to respect this decision, we are forced
to disable the warning globally.
SRW locks are available since Windows Vista. They work essentially like
Linux futexes. In particular, they can be statically initialized, and do
not require deinitialization. This makes them ideal for implementing
PTHREAD_MUTEX_INITIALIZER.
We still need CRITICAL_SECTION for recursive mutexes.
This file was rewritten from scratch in 0cef033, so it should be okay.
As mentioned in #730, it's a complete rewrite referencing only MSDN and
POSIX, rather than the original code.
This is useful in particular for GetLastError, unfortunately, it's stil pretty
dumb with regards to WASAPI or D3D specific errors, so keep the
hresult_to_string switch.
This covers source files which were added in mplayer2 and mpv times
only, and where all code is covered by LGPL relicensing agreements.
There are probably more files to which this applies, but I'm being
conservative here.
A file named ao_sdl.c exists in MPlayer too, but the mpv one is a
complete rewrite, and was added some time after the original ao_sdl.c
was removed. The same applies to vo_sdl.c, for which the SDL2 API is
radically different in addition (MPlayer supports SDL 1.2 only).
common.c contains only code written by me. But common.h is a strange
case: although it originally was named mp_common.h and exists in MPlayer
too, by now it contains only definitions written by uau and me. The
exceptions are the CONTROL_ defines - thus not changing the license of
common.h yet.
codec_tags.c contained once large tables generated from MPlayer's
codecs.conf, but all of these tables were removed.
From demux_playlist.c I'm removing a code fragment from someone who was
not asked; this probably could be done later (see commit 15dccc37).
misc.c is a bit complicated to reason about (it was split off mplayer.c
and thus contains random functions out of this file), but actually all
functions have been added post-MPlayer. Except get_relative_time(),
which was written by uau, but looks similar to 3 different versions of
something similar in each of the Unix/win32/OSX timer source files. I'm
not sure what that means in regards to copyright, so I've just moved it
into another still-GPL source file for now.
screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but
they're all gone.
Note that hresult_to_str() (coming from wasapi_explain_err()) is mostly
wasapi-specific, but since HRESULT error codes are unique, it can be
extended for any other use.
Windows definitely supports Unix-style fd inheritance. This mostly
worked when launched from mpv.exe, though mpv should change the file
mode to O_BINARY. When launched from mpv.com, the wrapper must pass the
list of handles (stored in the undocumented lpReserved2 and cbReserved2
fields) to the mpv process.
CSIDLs have been deprecated in Windows Vista and are not recommended for
use in new code. They have been replaced with Known Folder IDs, which
are pretty much the same thing, except they use GUIDs.
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.
This puts in place the machinery to merely append dropped file to the playlist
instead of replacing the existing playlist. In this commit, all front-ends
set this to false preserving the existing behaviour.
The waf build system generates this already. No point in redoing it in
the header file.
The legacy build system (which we really should drop) didn't; fix it.
This was originally done for zsh; but zsh can manage the terminal state
correctly when foregrounding/backgrounding applications if you enable it
with "ttyctl -f". So I see no reason to wake up the mpv process once
every second anymore.
Revert "win32: more wchar_t -> WCHAR replacements"
Revert "win32: replace wchar_t with WCHAR"
Doing a "partial" port of this makes no sense anymore from my
perspective. Revert the changes, as they're confusing without
context, maintenance, and progress. These changes were a bit
premature anyway, and might actually cause other issues
(locale neutrality etc. as it was pointed out).
This was essentially missing from commit 0b52ac8a.
Since L"..." string literals have the type wchar_t[], we can't use them
for UTF-16 strings. Use C11 u"..." string literals instead. These have
the type char16_t[], but we simply assume char16_t is the same
underlying type as WCHAR. In practice, they're both unsigned short.
For this reason use -std=c11 on Windows. Since Windows is a "special"
environment (we require either MinGW or Cygwin), we don't need to worry
too much about compiler compatibility.
WCHAR is more portable. While at least MinGW, Cygwin, and MSVC actually
use 16 bit wchar_t, Midipix will have 32 bit wchar_t. In that context,
using WCHAR instead is more portable.
This affects only non-MinGW parts, so not all uses of wchar_t need to
be changed. For example, terminal-win.c won't be used on Midipix at
all. (Most of io.c won't either, so the search & replace here is more
than necessary, but also not harmful.)
(Midipix is not useable yet, so this is just preparation.)
We used double-checked locking on pthread_mutex_t.requires_init in order
to lazily initialize static mutexes (since CRITICAL_SECTION has no
native way to do this). This was kind of unclean: we relied on MSVC
semantics for volatile (which apparently means all accesses are weakly
atomic), which is not such a good idea since mpv can't even be compiled
with MSVC.
Since it's too much of a pain to get weak atomics, just use INIT_ONCE
for initializing the CRITICAL_SECTION. Microsoft most likely implemented
this in an extremely efficient way. Essentially, it provides a mechanism
for correct double-checked locking without having to deal with the
tricky details. We still use an extra flag to avoid calling it at all
for normal locks.
(To get weak atomics, we could have used stdatomic.h, which modern MinGW
provides just fine. But I don't want this wrapper depend on MinGW
specifics if possible.)
See manpage additions.
The main reason for adding this is that we can't guess whether the user
wants his config in his Windows profile or not. The user basically has
to tell mpv what should be done, and the "portable_config" directory
does this implicitly.
Fixes#2042 (approximately).
It's conceivable that the OS time source is subject to clock changes.
The time could jump back to before when mpv was started, which would
cause mp_time_us() to return values smaller than 1. This is unexpected
by the code and could trigger assertions. If there's no monotonic time
source there's not much we can do anyway, so just sanitize the return
value. It will cause strange behavior until the "lost" time offset has
passed, but if you make such huge changes to the system clock while
everything is running, you're asking for trouble anyway.
(Normally we try to get a monotonic time source, though. This problem
sometimes happened on Windows when compiled without winpthreads, when
the code was falling back to gettimeofday(). This was already fixed by
always using another method.)
clock_gettime is implemented in winpthreads, so it's unavailable when
mpv is compiled with its internal pthreads implementation. This makes
mp_raw_time_us fall back to gettimeofday(), which can cause an assert
failure in mp_add_timeout() when the system clock is changed. Use
QueryPerformanceCounter instead.
The clock_gettime(CLOCK_MONOTONIC) implementation in winpthreads uses
QueryPerformanceCounter anyway, so there shouldn't be any change in
behaviour.
We want to distinguish actual errors, and just aborting the program
intentionally.
Also be a bit more careful with handling the wait() exit status: do not
called WEXITSTATUS() without checking WIFEXITED() first.
