summaryrefslogtreecommitdiffstats
path: root/osdep
Commit message (Collapse)AuthorAgeFilesLines
* subprocess: unblock/reset signals before running child processsfan52021-12-191-0/+21
| | | | | | | During execve() ignored and blocked signals carry over to the child process, though apparently for SIGCHLD (which the bug report was about) this is implementation-defined. fixes #9613
* libmpv: remove opengl_cb API and other deprecated symbolssfan52021-12-151-2/+1
| | | | | | Not all deprecated symbols were removed. Only three events were removed for now since these are not used internally. This bumps the library version to 2.0.
* build: add meson build supportDudemanguy2021-11-141-0/+1
| | | | | | Adds support for the meson build system as well as a bit of documentation. Compatibility with the existing waf build is maintained.
* osdep: rename MP_UNREACHABLENiklas Haas2021-11-031-2/+2
| | | | | It was pointed out on IRC that the name is misleading, since the actual semantics of the macro is to assert first.
* osdep: add MP_UNREACHABLENiklas Haas2021-11-031-0/+6
| | | | | | | | | This seems to work on gcc, clang and mingw as-is, but I made it conditional on __GNUC__ just in case, even though I can't figure out which compilers we care about that don't export this define. Also replace all instances of assert(0) in the code by MP_UNREACHABLE(), which is a strict improvement.
* win32: Windows 10: timeBeginPeriod on demandAvi Halachmi (:avih)2021-09-213-1/+72
| | | | | | | | | | | | | | | | | | | | | | | | Before this commit, timeBeginPeriod(1) was set once when mpv starts, and the timers remained hi-res till mpv exits. Now we do the same as before on Windows version < 10. On Windows 10+ we now use timeBeginPeriod if needed, per timeout. To force a mode regardless of Windows version, set env MPV_HRT: - "always": the old behavior - hires timers as long as mpv runs. - "perwait": sets 1ms timer resolution if timeout <= 50ms. - "never": don't use timeBeginPeriod at all. It was observed that on Windows 10 we lose about 0.5ms accuracy of timeouts with "perwait" mode (acceptable), but otherwise it works well for continuous timeouts (one after the other) and random ones. On Windows 7 with "perwait": continous timeouts are accurate, but random timeouts (after some time without timeouts) have bad accuracy - roughly 16ms resolution instead of the requested 1ms. Windows 8 was not tested, so to err on the side of caution, we keep the legacy behavior "always" by default.
* terminal-unix: identify and ignore unknown CSI sequencesAvi Halachmi (:avih)2021-08-191-0/+11
| | | | | | | | | | | | | | | If an unknown ESC sequence is detected where an ASCII char <X> follows the ESC, mpv interprets it as ALT+<X>, which is the traditional terminal encoding of ALT+letter. However, if <X> is '[' then it's a CSI sequence which continues after the '[', and has its own termination rules (can be many chars). Previously, mpv interpreted unknown CSI sequences as (incorrect) ALT+[ followed by (incorrect) "keys" from the rest of the sequence. In this commit, if a unknown CSI sequence is detected, mpv ignores exactly the complete sequence.
* terminal-unix: fix ^Z identificationMartin Tournoij2021-07-131-1/+2
| | | | | | | | | | | | | | When using "stty susp ''" to disable sending the TSTP signal with ^Z, mpv didn't recognize ^Z correctly in the terminal: [input] No key binding found for key 'Ctrl+2'. Because ASCII 26 (^Z) and above were incorrectly considered ^<NUMBER>. This commit moves the cutoff between letters/numbers from 25 to 26 so that ^Z is now detected correctly as ^<LETTER>. Additionally, it rephrases the ^<NUMBER> formula for clarity.
* mac: add ability to toggle visibility on all workspaces from menubarEvgeny Zinoviev2021-02-211-0/+7
|
* mac: only update touch bar items when necessaryder richter2021-02-132-87/+150
| | | | | | | | | | | | | | | | the slider on the touch bar was always updated when any of the related properties changed their value. this is partially dependent on the refresh rate of the video, in the case of time-pos. too many updates to touch bar impact the render performance. to prevent this we only update the slider when necessary, when the touch bar or the touch bar item is visible. the touch bar items only need a granularity of seconds without any decimals, but the time-pos property provides a granularity with decimals. we floor those values and only update the touch bar items when we have at least a 1 second difference. we also check for the visibility of the touch bar and its items. Fixes #8477
* mac: use custom touch bar item and slider instead of a touch bar sliderder richter2021-02-131-9/+9
| | | | | | | | | | | | | the NSSliderTouchBarItem seem to be broken in a way it can't be fixed. it has constraints set by default that can't be removed and lead to warnings and render performance regressions. instead of using the preconfigured NSSliderTouchBarItem we use a custom touch bar item (NSCustomTouchBarItem) with a slider, which essential are the same. this way we can configure our constraints ourselves, which aren't needed in the first place. Fixes: #7047
* mac: fix dangling pointersder richter2021-01-131-3/+15
| | | | | | initialising UnsafeMutableRawPointer the way we did won't free those pointers and we get dangling pointers. explicitly define a scope those pointers are alive and auto freed.
* mac: drop build support for swift versions earlier than version 4.1der richter2021-01-131-27/+0
| | | | | | | | | | | | this drops support for swift <4.1 and with this support for xcode <=9.2. this was the last setup that is officially working on macOS 10.12. our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13 + xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest version officially supported by Apple. this is in preparations for the following commit.
* mac: fix usage of temporary pointersder richter2021-01-132-29/+57
| | | | | | | | | | | the pointer used to initialise the respective structs is only guaranteed to be alive within this constructor. the struct itself is used later and the data it points to, is not guaranteed to be the same. to fix this we define a scope that pointer is definitely valid and use it within this scope. a helper function was added to get the pointers for several data at once. otherwise we would need to nest withUnsafeMutableBytes several times, which would make it hard to read.
* mac: use visible frame rectangle for window geometry calculationder richter2020-12-192-0/+8
| | | | | | | | | | | | | currently we use the whole screen rectangle to calculate the window geometry. this doesn't take the menu bar or the Dock into account. by default use the visible screen rectangle instead. this is also a change in behaviour, since the window can't be placed outside of this rectangle anymore. also add an option to change to the old behaviour, because it can still be useful in certain cases, like placing the window directly underneath the menu bar when used a desktop background. Fixes #8272
* terminal: process input when foregroundedGuido Cella2020-11-261-1/+9
| | | | | | | | | | When mpv is in the background because it was started with `mpv foo.mp3 &`, or the user did ctrl+z bg, and is then brought to the foreground with fg, it buffers input until you press enter. This makes it accept input almost immediately. Having a short interval isn't important, since input is buffered until the next loop iteration. Closes #8120.
* osdep/terminal: Add function to get terminal pixel dimensionsShreesh Adiga2020-11-224-0/+24
|
* path: do not use old_home for win32 exe dirwm42020-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works. Mistakenly reverted as part of the default configuration directory location switch-back in aa18a8e1cde663caeabd93af7d57a745c1a76af6. Separation of the mpv executable directory from old_path is a good change now that we warn about the old_config directory also existing. Fixes #8232 Fixes #8244 Fixes #8262
* Revert "path: switch back to using non-XDG config dir by default"Philip Langdale2020-10-161-7/+7
| | | | This reverts commit 269f0e743e5634691f0c9d5b1b8a4bb68eedbbd0.
* Revert "path: do not use old_home for win32 exe dir"Philip Langdale2020-10-161-1/+1
| | | | This reverts commit c3694f0acb7f71daac7606fafbadcb7b500ca35e.
* terminal: fix segfault when backgroundingwm42020-09-211-2/+4
| | | | | | | | | In the recent terminal commit, I "compressed" the read() error handling, and messed it up. The return value could be -1 for other non-fatal errors (such as EIO when trying to read while backgrounded), which resulted in buf.len getting messed up. Fixes: 602384348e718c77
* mac: add an option to change the App activation policyder richter2020-09-202-0/+3
| | | | useful to hide the app icon in the Dock if necessary.
* terminal: attempt to handle the ESC keywm42020-09-171-24/+22
| | | | | | | | | | | | | | | | | | Due to Unix being legacy garbage, it's not possible to safely detect the ESC key on terminal. The key sequences are ambiguous. The code for the ESC key also starts the sequences for other special keys. Until now, you needed to hit ESC twice for it to be recognized. Attempt to handle this better by using a timeout to detect the key. If ESC is in the input buffer, but nothing else arrived after a timeout, assume it's the ESC key. I think this is the method vim uses. Currently, the timeout is set at 100ms. This is hardcoded and cannot be changed. It's possible that this causes problems on slow ssh connections or so. I'm not sure what exactly happens if you manage to get ESC + another normal key into the input buffer. If it's a known sequence, it will be matched and interpreted as such. If not, it'll probably be discarded.
* terminal-unix: attempt to support more CTRLwm42020-09-101-6/+14
| | | | | | | Hysterically stupid inconsistent legacy garbage from the 70ies or maybe even 60ies. What the fuck. I fucking hate computers so much. Fixes: #8072
* mac: use config cache und wakeup for mac option runtime changesder richter2020-08-222-18/+24
| | | | | | | | remove the libmpv observer for the macOS specific options and use a config cache + change callback for runtime changes. this is also a preparation for new backends and generalises even more, since libmpv functions can't and shouldn't be used in usual vo backends. for feature parity the config cache is used.
* cocoa-cb: generalisation of backend independent partsder richter2020-08-224-20/+14
| | | | | | | | | | | | | move all backend independent code parts in their own folder and files, to simplify adding new backends. the goal is to only extend one class and add the backend dependent parts there. usually only the (un)init, config and related parts need to be implemented per backend. furthermore all needed windowing and related events are propagated and can be overwritten. the other backend dependent part is usually the surface for rendering, for example the opengl oder metal layer. in the best case a new backend can be added with only a few hundred lines.
* win32: scripting utils.get_env_list(): use UTF-8Avi Halachmi (:avih)2020-08-162-0/+15
| | | | | | | | | | | | | | | | lua/js utils.get_env_list() uses `environ' which was ANSI, thus it broke any unicode names/values. mpv already has an internal utf8_environ for win32, but it's used only at the getenv(..) wrapper and not exposed in itself, and also it has lazy initialization - on first getenv() call. Now `environ' maps to a function which ensures initialization while keeping it an l-value (like posix expects). The cost of this fuglyness is that files should include osdep/io.h (which now declares environ as extern) rather than declaring it themselves, or else the build will break on mingw.
* command: extend subprocess command stdin, change behaviorwm42020-08-162-4/+49
| | | | | | | | | | | | | | | Make it possible to feed a string to stdin of a subprocess. Out of laziness, it can't be an arbitrary byte string. (Would require adding an option type that takes in a Lua byte string.) Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore, because it makes things more consistent. Enabling stdin didn't make too much sense in the first place, so this behavior change seems justifiable. win32 support missing. Fixes: #8003
* win32: request the UTF-8 code page for Windows APIsJames Ross-Gowan2020-08-081-0/+1
| | | | | | | | | | | | | | This sets the activeCodePage property in the manifest, which forces the ANSI code page to be UTF-8 in Windows 10 1903 and up. It shouldn't make a difference for mpv itself, since mpv already uses the wide-char APIs for most functions, however some of mpv's dependencies, such as Lua, rely on the ANSI codepage. Hence this change enables support for Unicode file names in Lua's I/O library. Thanks @avih for finding this property. See: https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
* subprocess-win: update to mp_subprocess2James Ross-Gowan2020-07-204-140/+398
| | | | | | | | | | | | | | | | | | | This fixes the "run" and "subprocess" commands on Windows, including youtube-dl support. Unix-like FD inheritance is emulated on Windows by using an undocumented data structure[1] that gets passed to the newly created process in STARTUPINFO.lpReserved2. It consists of two sparse arrays listing the HANDLE and internal CRT flags corresponding to each FD. This structure is used and understood primarily by MSVCRT, but there are other runtimes and frameworks that can write it, like libuv. The code for creating asynchronous "anonymous" pipes in Windows has been enhanced and moved into windows_utils.c. This is mainly an artifact of an unfinished future change to support anonymous IPC clients in Windows. Right now, it's still only used in subprocess-win.c [1]: https://www.catch22.net/tuts/undocumented-createprocess
* command: extend subprocess commandwm42020-07-203-116/+3
| | | | | | | | | | | | | | | | | | | | Add env and detach arguments. This means the command.c code must use the "new" mp_subprocess2(). So also take this as an opportunity to clean up. win32 support gets broken by it, because it never made the switch to the newer function. The new detach parameter makes the "run" command fully redundant, but I guess we'll keep it for simplicity. But change its implementation to use mp_subprocess2() (couldn't do this earlier, because win32). Privately, I'm going to use the "env" argument to add a key binding that starts a shell with a FILE environment variable set to the currently playing file, so this is very useful to me. Note: breaks windows, so for example youtube-dl on windows will not work anymore. mp_subprocess2() has to be implemented. The old functions are gone, and subprocess-win.c is not built anymore. It will probably work on Cygwin.
* path: do not use old_home for win32 exe dirwm42020-06-251-1/+1
| | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works.
* path: switch back to using non-XDG config dir by defaultwm42020-06-251-7/+7
| | | | | | | | | | | | | | | | | | | | | XDG is stupid, so change back to the standard behavior. Unfortunately, most users will now have the XDG one, so we will still need to load this. (This is exactly the same problem as when XDG support was introduced, just the other way around). This should not affect any normal users. Hopefully I tested this well enough; my intention is not to torment miserable XDG fans; they can keep using their config dir if they want it. This changes behavior in two cases: - new users (now creates ~/.mpv/ instead of ~/.config/mpv/) - users which have both directories The latter case will behave subtly or obviously different, not sure. Just fix your shit. Extend the manpage with all the messy details, as far as I could reverse engineer them from the code.
* build: change filenames of generated fileswm42020-06-042-2/+2
| | | | Force them into a more consistent naming schema.
* terminal-win: handle 'Change Window Title' OSC sequenceJames Ross-Gowan2020-05-291-99/+131
| | | | | | | | | | | | | | | | | This should make --term-title work in Windows 8.1 and below. OSC sequences are defined in ECMA-48. The 'Change Window Title' command, as far as I can tell, is a de-facto standard defined by xterm[1]. In either case, this code is probably still not standards-compliant. This also changes mp_write_console_ansi to convert to UTF-16 before parsing control sequences, because that made it easier to pass the OSC param to SetConsoleTitleW. I think it's also more correct to do it this way, even though it doesn't really matter much for our limited terminal parsing. As a side-effect of this, mp_write_console_ansi no longer mutates its argument. [1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands
* osdep: remove confstr() fallback for subprocess spawningsfan52020-05-251-7/+2
| | | | | It doesn't exist on bionic (Android) and accurately emulating execvpe's behaviour isn't all that important.
* osdep: remove posix_spawn() helpers and wrapperswm42020-05-154-145/+1
| | | | See previous commit. Farewell, useless shitty POSIX function.
* subprocess: replace posix_spawnp() with fork()wm42020-05-151-17/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code runs posix_spawnp() within a fork() in some cases, in order to "disown" processes which are meant as being started detached. But posix_spawnp() is not marked as async-signal-safe, so what we do is not allowed. It could for example cause deadlocks, depending on implementation and luck at runtime. Turns out posix_spawnp() is useless crap. Replace it with "classic" fork() to ensure correctness. We could probably use another mechanism to start a process "disowned" than doing a double-fork(). The only problem with "disowning" a process is calling setsid() (which posix_spawnp() didn't support, but maybe will in newer revisions), and removing as as parent from the child process (the double-fork() will make PID 1 the parent). But there is no good way to either remove us as parent, or to "reap" the PID in a way that is safe and less of a mess than the current code. This is because POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives" like win32, no doubt.) Because POSIX/UNIX is a miserable heap of shit, execvp() is also not specified as async-signal-safe. It's funny how you can run a full fledged HTTP server in an async-signal-safe context, but not start a shitty damn process. Unix is really, really, really extremely bad at this process management stuff. So we reimplement execvp() in an async-signal-safe way. The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at different times, but both must be present. io.h defines them to 0 if they don't exist, and in this case the code will error out at runtime. Surely we could do without CLOEXEC via fallback, but I'll do that only if at least 1 bug is reported wrt. this issue. The idea how to report exec() failure or success is from musl. The way as_execvpe() is also inspired by musl (for example, the list of error codes that should make it fail is the same as in musl's code).
* w32_common: Support HiDPI on WindowsRealDolos2020-05-081-2/+3
|
* win32: SGR emulation: minor fixup on invalid sequenceAvi Halachmi (:avih)2020-04-241-2/+5
| | | | | | | | This fixes two issues with invalid value after 38/48: - It was not detected correctly and ended up skipping 4 instead of 0. - The intent was to skip 0, but it's better to skip the rest. Behavior with valid 2/5 after 38/48 was correct and is unaffected.
* osdep/terminal-win: native VT: report exact widthAvi Halachmi (:avih)2020-04-231-2/+3
| | | | | The narrower-by-1 width is not required with a native VT console because the wrapping behavior is the same as on *nix on such case.
* win32: native VT: logic fixupAvi Halachmi (:avih)2020-04-231-2/+2
| | | | | We want basemode unmodified so that we can use it if setting VT mode fails.
* win32: use windows 10 native virtual-terminal if availableAvi Halachmi (:avih)2020-04-231-2/+34
| | | | | | | | This enables native and more complete escape-sequence handling instead of our emulation. E.g. it supports 256/true colors, and more. This should get enabled automatically on Windows 10 build 16257 (August 2017) or later.
* win32: improve console SGR escape sequence emulationAvi Halachmi (:avih)2020-04-231-11/+50
| | | | | | | | | | | | | | | Previously an SGR sequence was emulated correctly only if: - It had exactly 1 or 2 numeric values (not 0). - Only reset, bold, and foreground colors were supported. - 256/true colors were not skipped correctly with their sub-values. Now it supports the same as before, plus: - 0-16 (inclusive) numeric values, e.g. \e[m now resets correctly. - Supports also codes for background color, reverse, underline* . - Supports also codes for default intensity/fg/bg/reverse/underline. - 256/true colors are recognized and skipped gracefully. * Reverse/underline seem to work only on windows 10.
* build: restore BSD thread names after 9f461b85bfa3Jan Beich2020-04-231-0/+4
| | | | | | | | | | | | | | On FreeBSD non-POSIX threading functions are in a separate header. DragonFly and OpenBSD adopted FreeBSD header and extensions. ../test.c:3:3: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration] { pthread_set_name_np(pthread_self(), "ducks"); return 0; } ^ ../osdep/threads.c:47:5: error: implicit declaration of function 'pthread_set_name_np' is invalid in C99 [-Werror,-Wimplicit-function-declaration] pthread_set_name_np(pthread_self(), tname); ^ Signed-off-by: Jan Beich <jbeich@FreeBSD.org>
* terminal-unix: add key_entry defs for DECCKM modeMurray Campbell2020-04-151-0/+4
| | | | | | | | zsh often sets DECCKM (i.e. Cursor Key Mode) meaning the arrow keys send `SS3 A/B/C/D` instead of `CSI A/B/C/D`. Add `key_entry` definitions for this alongside the existing DECCKM Reset definitions.
* win32: pthread: define PTHREAD_MUTEX_ERRORCHECKwm42020-03-191-0/+1
| | | | mpv uses it now. Doesn't need to do anything.
* osdep: add a pthread debugging wrapperwm42020-03-182-1/+82
| | | | | | | | | | | | | | | | | | | | Because pthread failures are virtually undebuggable (which sure is pretty strange, given all these heavy instrumentation tools these days). Of course it affects only files which include osdep/threads.h. I'm departing from the usual way to add symbols with config.h and using "#if", and defining it on the compiler command line + "#ifdef" because I don't want to include config.h from a header (which would be necessary in this case) to keep things slightly cleaner. Maybe this is misguided, but still. This would have been easier if mpv defined its own wrappers for all thread functions. But we don't (which to be honest is probably better than e.g. going crazy like VLC and essentially reimplementing everything). This seems to be a good compromise. Since it's off by default and basically a developer tool, the minor undefined behavior (redefining reserved symbols) isn't much of an issue.
* options: change option macros and all option declarationswm42020-03-181-24/+24
|