summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* input: change mp_cmd.original from bstr to cstrwm42019-11-233-6/+7
| | | | | | | | No reason to have this as bstr, just makes everything more complex. Also clear mp_cmd.sender when it's copied. Otherwise it would be a dangling pointer. Apparently it's never set to non-NULL in this situation, but this is cleaner anyway.
* input: make MP_INPUT_RELEASE_ALL a pseudo-keywm42019-11-222-3/+2
| | | | | | | Should be without consequences. I think this is less trouble, because code frequently wants to add/remove bits for modifiers and key state from key codes, and with this change you can't accidentally break it by testing or removing bits from the old -1 value.
* input: add text produced by key to script key eventswm42019-11-223-0/+7
| | | | | | | Particularly for "any_unicode" mappings, so they don't have to special-case keys like '#' and ' ', which are normally mapped to symbolic names for input.conf reasons. (Though admittedly, this is a pretty minor thing, since API users could map these manually.)
* input: introduce a pseudo key name that grabs all text inputwm42019-11-223-4/+14
| | | | | | | | | The intended target for this is the mpv.repl script, which manually added every single ASCII key as a separate key binding. This provides a simpler mechanism, that will catch any kind of text input. Due to its special nature, explicitly do not give a guarantee for compatibility; thus the warning in input.rst.
* input: fix ineffective mp_msg_test callwm42019-11-221-1/+1
| | | | | | This was supposed not to go through key lookup if the message wasn't going to be output, but for whatever reason the log levels were mismatched.
* options: remove M_OPT_FIXEDwm42019-11-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Options marked with this flag were changed to strictly read-only after initialization (mpv_initialize() in the client API, after option parsing and config file loading with the CLI player). This used to be necessary, because there was a single option struct that could be accessed by multiple threads. For example, --config-dir sets MPOpts.force_configdir, which was read whenever anything accessed the mpv config dir (which could be on different threads, e.g. font initialization tries to lookup fonts.conf from an arbitrary thread). This isn't needed anymore, because threads now access these in a thread safe way. In the case of --config-dir, the path is actually just copied on init. This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still prevents writing to some options that cannot take effect at runtime, but even that can be dropped. In general, all mpv options can be changed any time at runtime, even if they never take effect, and there's no need to make an exception for a very low number of options. So just get rid of it.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-311-6/+3
| | | | And remove libavutil includes where possible.
* sdl: prevent concurrent use of SDL in different threadswm42019-10-251-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | sdl_gamepad.c and vo_sdl.c both have their own event loops and run in separate threads. They don't know of each other (and shouldn't). Since SDL only has one global event loop (why didn't they fix this in SDL2?), these obviously clash. The actual behavior is relatively subtle, which event being randomly dispatched to either of the threads. This is very regrettable. Very. Work this around. "Fortunately" SDL exposes its global state to some degree. SDL_WasInit() returns whether a "subsystem" was initialized, and you could say the one who initialized it owns it. Both SDL_INIT_VIDEO and SDL_INIT_GAMECONTROLLER implicitly enable SDL_INIT_EVENTS, and the event loop is indeed the resource that cannot be shared. Unfortunately, this is still racy, since SDL_InitSubSystem is a second call, and succeeds if the subsystem is already initialized (increases a refcount I think). But good enough. Blame SDL for everything. (I think I made this commit message too long. Nobody cares even.) Fixes: #7085
* input: disable gamepad code by defaultwm42019-10-251-3/+0
| | | | | | | Enabling this by default probably causes a number of issues, such as breaking vo_sdl, or reacting to various input devices while the window is not focused. It's also pretty obscure, or at least new. Disable it by default.
* sdl_gamepad: fix typo in function namewm42019-10-251-2/+2
| | | | As pointed out by LaserEyess on IRC.
* sdl_gamepad: fix function signaturewm42019-10-251-1/+1
| | | | This is semantically different in C.
* input: add gamepad support through SDL2Stefano Pigozzi2019-10-235-0/+346
| | | | | | | | | | | | | | | The code is very basic: - only handles gamepads, could be extended for generic joysticks in the future. - only has button mappings for controllers natively supported by SDL2. I heard more can be added through env vars, there's also ways to load mappings from text files, but I'd rather not go there yet. Common ones like Dualshock are supported natively. - analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an activation threshold. - only supports one gamepad at a time. the feature is intented to use gamepads as evolved remote controls, not play multiplayer games in mpv :)
* 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