summaryrefslogtreecommitdiffstats
path: root/osdep
Commit message (Collapse)AuthorAgeFilesLines
* input: add append argument to file drop eventKevin Mitchell2015-08-301-1/+1
| | | | | | 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.
* atomics: cleanup HAVE_ATOMICS definewm42015-08-131-5/+0
| | | | | | | 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.
* terminal: disable terminal foreground state pollingwm42015-08-011-2/+1
| | | | | | | 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.
* win32: revert wchar_t changeswm42015-08-014-21/+21
| | | | | | | | | | | 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).
* win32: more wchar_t -> WCHAR replacementswm42015-07-301-1/+1
| | | | | | | | | | | | | 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.
* win32: replace wchar_t with WCHARwm42015-07-293-20/+20
| | | | | | | | | | | | | 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.)
* win32: pthread: don't play dirty tricks for mutex initwm42015-07-272-28/+10
| | | | | | | | | | | | | | | | | | | | 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.)
* win32: add portable config modewm42015-07-271-9/+30
| | | | | | | | | | | 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).
* player: use exit code 0 by default for quit, 4 for signals, etc.Philip Sequeira2015-07-111-1/+1
| | | | | | Default key bindings in encoding mode also use code 4, because scripts will probably want to fail if encoding is aborted (leaving an incomplete file).
* timer: fix a corner case on clock changeswm42015-07-041-1/+4
| | | | | | | | | | | | | | | | 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.)
* win32: use QueryPerformanceCounter for timingJames Ross-Gowan2015-07-041-13/+11
| | | | | | | | | | | | 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.
* subprocess, lua: export whether the process was killed by uswm42015-06-273-3/+13
| | | | | | | | 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.
* terminal-unix: set terminal mode on initwm42015-06-271-1/+1
| | | | | | | | | | | | | | | mpv usually sets the terminal to non-canonical mode (which in particular disables line buffering). But the old mode is restored if the process is not foregrounded. This is supposed to make mpv behave nicer when it is backgrounded. getch2_poll() enables canonical mode. Unfortunately, this was only called after the poll timeout elapsed, so non-canonical mode is first enabled after about a second after program start. Fix this by moving the poll call before the timeout. (As far as we're aware, there's no event-based way to determine when the FD's process group changes, thus we're polling.)
* Revert "win32: add mappings for some special keys"wm42015-06-241-9/+0
| | | | | | | This reverts commit fc9695e63b5baa1a478acb8e79c038571ee0e9b3. Users were complaining that both mpv and something else (what? I don't know) respond to some multimedia keys, such as volume change.
* Various spelling fixesMarcin Kurczewski2015-06-181-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* osx: add NULL check for input context in a missing casewm42015-06-011-1/+2
| | | | Fixes a crash on exit under certain circumstances.
* osx: synchronize access to the input_ctxwm42015-05-261-18/+30
| | | | | | | | | | While all functions of input_ctx are inherently thread-safe, access to the _inputContext field itself is not. It could be unset any time by cocoa_set_input_context(). So even trivial input_ctx calls must be under a lock, so that the input_ctx can not be destroyed while the function call is "starting". (Even a function call in progress wouldn't be fine, because mp_input_uninit() requires the caller to "own" the object, i.e. no other threads can access it at this point.)
* osx: never expose input_ctx from EventsResponderwm42015-05-263-20/+33
| | | | Keep it internal, so we can synchronize access to it properly.
* win32: do not call timeEndPeriod(1) on terminationwm42015-05-211-8/+0
| | | | | | | | This was called for formal reasons at best. The way it does this is somewhat dangerous, because if libmpv is unloaded as DLL, this would attempt to call a dangling function pointer. (No, we don't want an extra DllMain entrypoint just for win32.)
* Remove trailing whitespacesMichael Vetter2015-05-152-200/+200
|
* win32: add mappings for some special keyswm42015-05-121-0/+9
| | | | Untested.
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-114-23/+11
| | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.)
* ao: make better use of atomicswm42015-05-111-0/+1
| | | | | The main reason for this was compatibility; but some associated problems have been solved in the previous commit.
* atomics: add atomic_fetch_and/atomic_fetch_orwm42015-05-111-7/+20
| | | | | | | | | | As usual, we prefer plain C11 names and semantics, and have to emulate them if C11 atomics are not available. For the non-atomic fallback (which is just there to make code compile in situations the atomic property is not overly important), we require a gross hack to make the generic macros work without using compiler- specific extensions.
* Always block SIGPIPE globallywm42015-05-111-3/+0
| | | | | | | | | | | | | | | OpenSSL and GnuTLS are still causing this problem (although FFmpeg could be blamed as well - but not really). In particular, it was happening to libmpv users and in cases the pseudo-gui profile is used. This was because all signal handling is in the terminal code, so if terminal is disabled, it won't be set. This was obviously a questionable shortcut. Avoid further problems by always blocking the signal. This is done even for libmpv, despite our policy of not messing with global state. Explicitly document this in the libmpv docs. It turns out that a version bump to 1.17 was forgotten for the addition of MPV_FORMAT_BYTE_ARRAY, so document that change as part of 1.16.
* build: exclude -Wredundant-declswm42015-05-091-2/+0
| | | | | | | It's useless, and creates a bogus warning in subprocess-posix.c. Since I don't know which compilers might have it by default, just change it to -Wno-redundant-decls.
* path: make mp_path_join accept normal C stringswm42015-05-092-3/+3
| | | | | Instead of bstr. Most callers of this function do not need bstr. The bstr version of this function is now mp_path_join_bstr().
* subprocess-win: use the correct pipe namespaceJames Ross-Gowan2015-05-041-1/+1
| | | | | | This was a mistake, it should definitely be using the device namespace rather than the file namespace. As it says in the docs, all pipe names must start with \\.\pipe\
* win32: fix desktop directorywm42015-05-031-1/+1
| | | | The folder argument wasn't used, so it always returned the APPDATA dir.
* win32: move platform specifics to osdepwm42015-05-021-0/+28
| | | | | This will probably disable this code for Cygwin. I don't know if this matters, since Cygwin should strictly behave like a Unix anyway.
* build: move main-fn files to osdepwm42015-05-026-7/+76
| | | | | | And split the Cocoa and Unix cases. Simplify the Cocoa case slightly by calling mpv_main directly, instead of passing a function pointer. Also add a comment explaining why Cocoa needs a special case at all.
* cocoa: always compile OSX application code with cocoawm42015-05-023-11/+15
| | | | | | | | | | | | | | This unbreaks compiling command line player and libmpv at the same time. The problem was that doing so silently disabled the OSX application thing - but the command line player can not use the vo_opengl Cocoa backend without it. The OSX application code is basically dead in libmpv, but it's not that much code anyway. If you want a mpv binary that does not create an OSX application singleton (and creates a menu etc.), you must disable cocoa completely, as cocoa can't be used anyway in this case.
* path: update path descriptionswm42015-05-021-1/+2
|
* path: add resolving desktop path to platform-specific pathswm42015-05-013-2/+14
| | | | | | | | | win32 has a special function for this. I'm not sure about OSX - it seems ~/Desktop can be hardcoded, and the OSX GUI actually localizes the _displayed_ path in its UI. For Unix, there is not much to be done, or is there.
* timer: add "static" to a variablewm42015-05-011-1/+1
|
* path: refactorwm42015-05-014-25/+98
| | | | | | | | | | | | | | Somewhat less ifdeffery, higher flexibility. Now there are 3 separate config file resolvers for 3 platforms (unix, win, osx), and they can still interact with each other somewhat. For example, OSX for now uses most of Unix, but adds the OSX bundle path. This can be extended to resolve very specific platform paths, such as location of the desktop. Most of the Unix specific code moves to path-unix.c. The behavior should be the same - if not, it is likely a bug.
* terminal: printf() is not signal-safewm42015-04-241-2/+1
| | | | We shouldn't call it from a signal handler.
* subprocess: move implementation for deatched subprocesseswm42015-04-152-0/+60
|
* subprocess-posix: always connect stdin to /dev/nullwm42015-04-151-1/+12
| | | | | | | | It appears youtube-dl sometimes asks for a password on stdin. This won't work, because mpv already uses the terminal. (I wonder if this could be simpler, like simply closing FD 0, but let's not. The FD would be reused by something random.)
* Update license headersMarcin Kurczewski2015-04-1313-49/+41
| | | | Signed-off-by: wm4 <wm4@nowhere>
* win32: only attach to the console from mpv.comJames Ross-Gowan2015-04-113-13/+44
| | | | | | | | | | | | | | | | | | | 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.
* win32: use a platform-specific unicode entry-pointJames Ross-Gowan2015-04-112-28/+0
| | | | | | | | | | Add a platform-specific entry-point for Windows. This will allow some platform-specific initialization to be added without the need for ugly ifdeffery in main.c. As an immediate advantage, mpv can now use a unicode entry-point and convert the command line arguments to UTF-8 before passing them to mpv_main, so osdep_preinit can be simplified a little bit.
* subprocess-win: clarify argument escaping logicJames Ross-Gowan2015-03-241-8/+8
| | | | This bit always seemed confusing to me.
* subprocess-win: handle empty arguments correctlyJames Ross-Gowan2015-03-241-0/+6
|
* osx: terminate argv properly when arguments are removedwm42015-03-061-1/+4
| | | | | | | The player now relies on the (slightly obscure) requirement that argv is NULL-terminated. Might fix #1652.
* cocoa: silence -Wlogical-op-parenthesesStefano Pigozzi2015-03-041-1/+1
|
* msg: use relaxed atomics for log level testwm42015-03-021-0/+5
| | | | | | This should be sufficient. If stdatomic.h is not available, we make no difference.
* cocoa: remove unused functionStefano Pigozzi2015-02-141-7/+0
|
* cocoa: fix exiting the command line playerwm42015-02-131-4/+3
| | | | | | | | Commit e920a00eb assumed that terminate_cocoa_application() actually would exit. But apparently that is not always the case; e.g. mpv --help will just hang. The old code had a dummy exit(0), which was apparently actually called. Fix by explicitly exiting if mpv_main() returns and terminate_cocoa_application() does nothing.
* osx: move cocoa specific call out of common codewm42015-02-121-0/+2
| | | | This is almost equivalent, and gets rid of the ifdef.
* win32: fix/change application namewm42015-02-092-3/+3
| | | | Pointed out in #935 (again).
* osdep/subprocess-posix: remove __GLIBC__ guardKevin Mitchell2015-02-031-3/+2
| | | | | It's the wrong thing to check. For example it doesn't work on cygwin. Just live with the warning.
* msg: add --log-file optionwm42015-01-262-1/+3
| | | | | | | | | This allows getting the log at all with --no-terminal and without having to retrieve log messages manually with the client API. The log level is hardcoded to -v. A higher log level would lead to too much log output (huge file sizes and latency issues due to waiting on the disk), and isn't too useful in general anyway. For debugging, the terminal can be used instead.
* win32: use monotonic clock on windows if possibleHiltjo Posthuma2015-01-191-0/+10
|
* subprocess-win: Always quote argv[0]James Ross-Gowan2015-01-161-3/+5
| | | | | | | | | | | | | If the program name isn't quoted and the .exe it refers to isn't found, CreateProcess will add the program arguments to the program name and continue searching, so for "program arg1 arg2", CreateProcess would try "program.exe", "program arg1.exe", then "program arg1 arg2.exe". This behaviour is weird and not really desirable, so prevent it by always quoting the program name. When quoting argv[0], escape sequences shouldn't be used. msvcrt, .NET and CommandLineToArgvW all treat argv[0] literally and end it on the trailing quote, without processing escape sequences.
* win32: request UTF-16 API variants, Vista+ APIs, and COM C macroswm42015-01-071-1/+0
| | | | | Put the Vista+ (_WIN32_WINNT) and the COM C (COBJMACROS) defines into the build system, instead of defining them over and over in the code.
* terminal: always print to stderr with --no-input-terminalwm42015-01-071-5/+6
| | | | | | | | | | | | | | | | | The function terminal_in_background() reports whether the player was backgrounded. In this case, we don't want to annoy the user by still printing the status to stderr. If no terminal interaction is assumed, this mechanism is disabled, and stderr is always used. The read_terminal variable signals this case. Oddly, just redirecting stderr will disable output to stderr, because the background check with tcgetpgrp() is done on stderr, but read_terminal is still true (because that one depends on stdin and stdout). Explicitly disable this mechanism if --no-input-terminal is used by setting read_terminal to true only if terminal input is actually initialized.
* player: use libavutil API to get number of CPUswm42015-01-052-67/+0
| | | | | | | | | | | Our own code was introduced when FFmpeg didn't provide this API (or maybe didn't even have a way to determine the CPU count). But now, av_cpu_count() is available for all FFmpeg/Libav versions we support, and there's no reason to have our own code. libavutil's code seems to be slightly more sophisticated than our's, and it's possible that the detected CPU count is different on some platforms after this change.
* subprocess: allow disabling redirection of stdout/stderrwm42015-01-012-6/+10
| | | | | | | | | If the stdout or stderr write callback is NULL, then don't redirect this stream. Preparation for the next commit. Not sure what to do on Windows; it seems STARTUPINFO doesn't allow redirection only one of them. So just let them write nothing. For our intended use-case (next commit), this is probably sensible.
* win32: add native wrappers for pthread functionswm42015-01-013-0/+380
| | | | | | | Off by default, use --enable-win32-internal-pthreads . This probably still needs a lot more testing. It also won't work on Windows XP.
* Update copyright yearwm42015-01-011-1/+1
|
* win32: add mmap() emulationwm42014-12-262-0/+74
| | | | | | | | Makes all of overlay_add work on windows/mingw. Since we now don't explicitly ch