summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* input: add keybind commandDudemanguy9112019-09-212-0/+41
|
* input: ignore empty lines on drag-drop mime datathewisenerd2019-09-211-1/+1
| | | | do not outright err and quit the player for this
* Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into ↵Anton Kindestam2018-12-057-143/+212
|\ | | | | | | | | | | wm4-commits--merge-edition This bumps libmpv version to 1.103
| * player: get rid of mpv_global.optswm42018-05-243-5/+14
| | | | | | | | | | | | | | | | This was always a legacy thing. Remove it by applying an orgy of mp_get_config_group() calls, and sometimes m_config_cache_alloc() or mp_read_option_raw(). win32 changes untested.
| * input: remove now unused "abort command" and cancel infrastructurewm42018-05-244-70/+2
| | | | | | | | The previous commit removed all uses.
| * player: make various commands for managing external tracks abortablewm42018-05-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, they could be aborted only by ending playback, and calling mpv_abort_async_command didn't do anything. This requires furthering the mess how playback abort is done. The main reason why mp_cancel exists at all is to avoid that a "frozen" demuxer (blocked on network I/O or whatever) cannot freeze the core. The core should always get its way. Previously, there was a single mp_cancel handle, that could be signaled, and all demuxers would unfreeze. With external files, we might want to abort loading of a certain external file, which automatically means they need a separate mp_cancel. So give every demuxer its own mp_cancel, and "slave" it to whatever parent mp_cancel handles aborting. Since the mpv demuxer API conflates creating the demuxer and reading the file headers, mp_cancel strictly need to be created before the demuxer is created (or we couldn't abort loading). Although we give every demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer), it's still rather messy to create/destroy it along with the demuxer.
| * cmd: do not use a random value for MP_CMD_OPT_ARGwm42018-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | This flag is used only by the command parser. Its value overlapped with some of the existing m_option flags, but only flags that did not matter for the command parser (i.e. the flag bits used had mostly private uses in each component). It's still a bit unclean and dangerous to use an essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it. Since M_OPT_OPTIONAL_PARAM has a slightly longer name than MP_CMD_OPT_ARG, I'm going to keep the old name.
| * input: slightly improve --input-cmdlist outputwm42018-05-241-5/+6
| | | | | | | | | | Output argument names, whether varargs are used, and indicate optional arguments correctly (instead of only half of them).
| * command: give named arguments to almost all commandswm42018-05-241-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, only 1 command or so had named arguments. There is no reason why other commands can't have them, except that it's a bit of work to add them. Commands with variable number of arguments are inherently incompatible to named arguments, such as the "run" command. They still have dummy names, but obviously you can't assign multiple values to a single named argument (unless the argument has an array type, which would be something different). For now, disallow using named argument APIs with these commands. This might change later. 2 commands are adjusted to not need a separate default value by changing flag constants. (The numeric values are C only and can't be set by users.) Make the command syntax in the manpage more consistent. Now none of the allowed choice/flag names are in the command header, and all arguments are shown with their proper name and quoted with <...>. Some places in the manpage and the client.h doxygen are updated to reflect that most commands support named arguments. In addition, try to improve the documentation of the syntax and need for escaping etc. as well. (Or actually most uses of the word "argument" should be "parameter".)
| * ipc: some user-visible changes to prepare for making all commands asyncwm42018-05-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I wanted to put all commands through mpv_command_node_async() instead of mpv_command_node(). Using synchronous commands over a synchronous transport doesn't make sense anyway. This would have used the request_id field in IPC requests as reply ID for the async commands. But the latter need to be [u]int64, while the former can be any type. To avoid that we need an extra lookup table for mapping reply IDs to request_id values, we now require that request_id fields are integers. Since this would be an incompatible change, just deprecate non-integers for now, and plan the change for a later time.
| * ipc: cosmetic: switch a negated if/elsewm42018-05-241-3/+3
| |
| * ipc: alias set_property_string to set_propertywm42018-05-241-20/+3
| | | | | | | | | | | | | | | | | | The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
| * command: add a way to abort asynchronous commandswm42018-05-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Many asynchronous commands are potentially long running operations, such as loading something from network or running a foreign process. Obviously it shouldn't just be possible for them to freeze the player if they don't terminate as expected. Also, there will be situations where you want to explicitly stop some of those operations explicitly. So add an infrastructure for this. Commands have to support this explicitly. The next commit uses this to actually add support to a command.
| * command: add a subprocess commandwm42018-05-241-0/+1
| | | | | | | | | | | | | | This supports named arguments. It benefits from the infrastructure of async commands. The plan is to reimplement Lua's utils.subprocess() on top of it.
| * input: add glue code for named argumentswm42018-05-241-42/+143
| | | | | | | | | | | | | | | | | | | | Named arguments should make it easier to have long time compatibility, even if command arguments get added or removed. They're also much nicer for commands with a large number of arguments, especially if many arguments are optional. As of this commit, this can not be used, because there is no command yet which supports them. See the following commit.
| * node: move a mpv_node helper from ipc.c to shared codewm42018-05-241-14/+3
| | | | | | | | This particular one is needed in a following commit.
| * input: add a define for the number of mouse buttons and use itwm42018-05-241-0/+2
| | | | | | | | (Why the fuck are there up to 20 mouse buttons?)
| * input: remove unused fieldwm42018-05-241-1/+0
| | | | | | | | This was forgotten in commit fb9bbf2a0d7f8.
| * command: add infrastructure for async commandswm42018-05-242-2/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables two types of command behavior: 1. Plain async behavior, like "loadfile" not completing until the file is fully loaded. 2. Running parts of the command on worker threads, e.g. for I/O, such as "sub-add" doing network accesses on a thread while the core continues. Both have no implementation yet, and most new code is actually inactive. The plan is to implement a number of useful cases in the following commits. The most tricky part is handling internal keybindings (input.conf) and the multi-command feature (concatenating commands with ";"). It requires a bunch of roundabout code to make it do the expected thing in combination with async commands. There is the question how commands should be handled that come in at a higher rate than what can be handled by the core. Currently, it will simply queue up input.conf commands as long as memory lasts. The client API is limited by the size of the reply queue per client. For commands which require a worker thread, the thread pool is limited to 30 threads, and then will queue up work in memory. The number is completely arbitrary.
| * input: move an enum back to its correct placewm42018-05-242-13/+13
| | | | | | | | This was accidentally moved together with the cmd stuff.
| * command: handle list commands like normal commandswm42018-05-241-4/+0
| | | | | | | | Pretty annoying.
* | ipc-unix: don't blow up on readonly fd://Niklas Haas2018-10-311-1/+1
| | | | | | | | | | | | On my system, when trying to use mpv with a read-only fd created by python 3.7, `send` triggers ENOTSOCK, not EBADF. Extend the logic to detect non-writable fds by this `errno`.
* | ipc-unix: leave room for a NUL terminatorBen Boeckel2018-10-311-1/+1
| | | | | | | | | | | | | | The `strncpy` function will not always place a terminating `NUL` if the source is longer than the destination buffer. Instead, let `strncpy` truncate as it normally would, but leave the last byte alone (it is zero-initialized when declared).
* | cmd: do not use a random value for MP_CMD_OPT_ARGwm42018-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | This flag is used only by the command parser. Its value overlapped with some of the existing m_option flags, but only flags that did not matter for the command parser (i.e. the flag bits used had mostly private uses in each component). It's still a bit unclean and dangerous to use an essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it. Since M_OPT_OPTIONAL_PARAM has a slightly longer name than MP_CMD_OPT_ARG, I'm going to keep the old name.
* | ipc: cosmetic: switch a negated if/elsewm42018-05-251-3/+3
| |
* | ipc: alias set_property_string to set_propertywm42018-05-251-20/+3
| | | | | | | | | | | | | | | | | | The only effective difference is that the former explicitly checks whether the JSON value type is string, and errors out if not. The rest is exactly the same (mpv_set_property_string is mpv_set_property with MPV_FORMAT_STRING). It seems silly to keep this, so just remove it.
* | input: move an enum back to its correct placewm42018-05-252-13/+13
| | | | | | | | This was accidentally moved together with the cmd stuff.
* | input: add a define for the number of mouse buttons and use itwm42018-05-251-0/+2
|/ | | | (Why the fuck are there up to 20 mouse buttons?)
* input: rename weirdly named functionwm42018-05-033-4/+5
|
* input: move some more cmd definitions to cmd.hwm42018-05-032-64/+64
| | | | | | Now both command "descriptions" and runtime command instances are in cmd.h, which makes sense to me. input.h is now for the actual input context.
* input: merge cmd_list.c with cmd.cwm42018-05-035-144/+87
| | | | | | It doesn't really make sense to keep a separate cmd_list.c file, which does _not_ contain a command list, but only a few minor helper functions.
* input: rename cmd_parse.c to cmd.cwm42018-05-031-0/+0
| | | | | Done separately from the cmd.h rename to avoid issues with git being bad at tracking mixed content and filename changes.
* input: rename cmd_parse.h to cmd.hwm42018-05-035-5/+3
|
* command: split big command handler switch into separate functionswm42018-05-032-91/+4
| | | | | | | | | | | | | | | | | | | This gets rid of run_command() and its big switch statement, which was an idiotically big function of almost 1000 lines. The switch is replaced with a callback per command, and each command is now implemented in its own function. Command IDs are not needed anymore, so the mp_command_type enum disappears. There should be no functional changes, but since this refactors 64 commands, regressions are possible. The handler() parameter is void*, because in theory the input code is supposed to be independent of the player core code. For example, you should be able to reuse the command parser code for some other part of mpv. In practice, the variable containing command list is defined in the player core anyway, so you could say this doesn't work. But I'm still trying to hold onto this idea, so I went with void*.
* input: remove some explicit uses of command IDswm42018-05-035-20/+20
| | | | | | | | | | The plan is to remove the command ID enum. This will happen by replacing the big switch statement in command.c with dispatching to per-command callbacks. As preparation, remove uses of the command IDs outside of the actual dispatching mechanism. Also remove some instances of checking cmd->def for NULL. We now require this always to be set.
* input: remove legacy command handlingwm42018-05-033-84/+0
| | | | | | | | These are old MPlayer commands that were redundant since 2007 or so. In 2013, mpv explicitly deprecated them (actually removed them, but left this wrapper, which translated them to modern commands). The list was not extended since 2013, and mpv always warned on the terminal when a legacy command was used. So it's time to remove it.
* input: move command list to command.cwm42018-05-031-215/+0
| | | | Preparation for more changes.
* input: raise log level of some noisy messageswm42018-04-291-7/+7
| | | | Same as the commit before this.
* client API: add a first class hook API, and deprecate old APIwm42018-03-261-1/+1
| | | | | | | | | | | | | | | As it turns out, there are multiple libmpv users who saw a need to use the hook API. The API is kind of shitty and was never meant to be actually public (it was mostly a hack for the ytdl script). Introduce a proper API and deprecate the old one. The old one will probably continue to work for a few releases, but will be removed eventually. There are some slight changes to the old API, but if a user followed the manual properly, it won't break. Mostly untested. Appears to work with ytdl_hook.
* all: replace mpv_detach_destroy() with mpv_destroy()wm42018-03-152-4/+4
|
* command: add a change-list commandwm42018-01-252-0/+2
| | | | | | | | | | | | | Requested. See manpage additions. The main reason why this goes through the trouble to keep the action/operation parameter separate is so that we don't expose some option parser implementation details to the command (although that is a relatively weak reason), and also to make it more different from the "set" command, which can't support this type of option as it goes through the property layer. Fixes #5435.
* cmd_parse: minor cosmeticswm42018-01-181-5/+2
|
* ta: introduce talloc_dup() and use it in some placeswm42018-01-181-3/+3
| | | | | | | It was actually already implemented as ta_dup_ptrtype(), but that seems like a clunky name. Also we still use the talloc_ names throughout the source, and I'd rather use an old name instead of a mixing inconsistent naming conventions.
* input: make command argument list a dynamic arraywm42018-01-104-52/+55
| | | | | | | | Replace the static array with dynamic memory allocation. This also requires some code to honor mp_cmd.nargs more strictly. Generally allocates more stuff. Fixes #5375 (although we could also just raise the static limit).
* player: remove internal `vo-resize` command againsfan52018-01-022-2/+0
| | | | Its only usecase was automated in the previous commit.
* player: add internal `vo-resize` commandsfan52017-12-272-0/+2
| | | | Intended to be used with the properties from previous commit.
* msg: reinterpret a bunch of message levelsNiklas Haas2017-12-151-11/+11
| | | | | | | | | | | | | | | | | | | | | | I've decided that MP_TRACE means “noisy spam per frame”, whereas MP_DBG just means “more verbose debugging messages than MSGL_V”. Basically, MSGL_DBG shouldn't create spam per frame like it currently does, and MSGL_V should make sense to the end-user and provide mostly additional informational output. MP_DBG is basically what I want to make the new default for --log-file, so the cut-off point for MP_DBG is if we probably want to know if for debugging purposes but the user most likely doesn't care about on the terminal. Also, the debug callbacks for libass and ffmpeg got bumped in their verbosity levels slightly, because being external components they're a bit less relevant to mpv debugging, and a bit too over-eager in what they consider to be relevant information. I exclusively used the "try it on my machine and remove messages from MSGL_* until it does what I want it to" approach of refactoring, so YMMV.
* ipc: avoid dereferencing NULLMartin Shirokov2017-12-151-7/+17
| | | | | This can happen when ctr->client_api->shutting_down is set to true, or when there are over 1000 clients with the same name passed to mp_new_client().
* input: remove a stray HAVE_GPLwm42017-11-291-2/+0
| | | | | | | This was marked GPL, because the implementation in command.c (which is shared with the subtitle code) was marked as GPL. This has been changed, so this is unnecessary. The original commands for external audio tracks have been added to mpv by someone who agreed with the relicensing.
* player: change 3 remaining GPL-only code pieces to LGPLwm42017-11-241-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There has been no new developments or agreements, but I was uncertain about the copyright status of them. Thus this part of code was marked as being potentially GPL, and was not built in LGPL mode. Now I've taken a close look again, and decided that these can be relicensed using the existing relicensing agreements. OSD level 3 was introduced in commit 8d190244, with the author being unreachable. As I decided in commit 6ddd95fd, OSD level 3 itself can be kept, but the "osd" command had to go, and the "rendering" of OSD level 3 (the HAVE_GPL code in osd.c) was uncertain. But the code for this was rewritten: instead of duplicating the time/percent formatting code, it was changed to use common code, and some weird extra logic was removed. The code inside of the "if" is exactly the same as the code that formats the OSD status line (covered by LGPL relicensing). The current commands for adding/removing sub/audio tracks more or less originated from commit 2f376d1b39, with the author being unreachable. But the original code was very different, mostly due to MPlayer's incredibly messy handling of subtitles in general. Nothing of this remains in the current code. Even the command declarations were rewritten. The commands (as seen from the user side) are rather similar in naming and semantics, but we don't consider this copyrightable. So it doesn't look like anything copyrightable is left. The add/cycle