summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* 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 commands were more or less based on step_property, introduced in commit 7a71da01d6, with the patch author disagreeing with the LGPL relicensing. But all code original to the patch has been replaced in later mpv changes, and the original code was mostly copied from MP_CMD_SET_PROPERTY anyway. The underlying property interface was completely changed, the error handling was redone, and all of this is very similar to the changes that were done on SET_PROPERTY. The command declarations are completely different in the first place, because the semantic change from step to add/cycle. The commit also seems to have been co-authored by reimar to some degree. He also had the idea to change the original patch from making the command modify a specific property to making it generic. (The error message line, especially with its %g formatting, might contain some level of originality, so change that just to be sure. This commit Copies and adapts the error message for SET_PROPERTY.) Although I'm a bit on the fence with all the above things, it really doesn't look like there's anything substantial that would cause issues. I thus claim that there is no problem with changing the license to LGPL for the above things. It's probably still slightly below the standard that was usually applied in the code relicensing in mpv, but probably still far above to the usual in open source relicensing (and above commercial standards as well, if you look what certain tech giants do).
* build: add preliminary LGPL modewm42017-09-211-0/+2
| | | | | | | See "Copyright" file for caveats. This changes the remaining "almost LGPL" files to LGPL, because we think that the conditions the author set for these was finally fulfilled.
* input: fix error in MP_KEY_IS_WHEELJames Ross-Gowan2017-09-031-1/+1
| | | | Whoops.
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-034-86/+74
| | | | | | | | | | | | | | | | | | | | | | Mouse wheel bindings have always been a cause of user confusion. Previously, on Wayland and macOS, precise touchpads would generate AXIS keycodes and notched mouse wheels would generate mouse button keycodes. On Windows, both types of device would generate AXIS keycodes and on X11, both types of device would generate mouse button keycodes. This made it pretty difficult for users to modify their mouse-wheel bindings, since it differed between platforms and in some cases, between devices. To make it more confusing, the keycodes used on Windows were changed in 18a45a42d524 without a deprecation period or adequate communication to users. This change aims to make mouse wheel binds less confusing. Both the mouse button and AXIS keycodes are now deprecated aliases of the new WHEEL keycodes. This will technically break input configs on Wayland and macOS that assign different commands to precise and non-precise scroll events, but this is probably uncommon (if anyone does it at all) and I think it's a fair tradeoff for finally fixing mouse wheel-related confusion on other platforms.
* input: use mnemonic names for mouse buttonsJames Ross-Gowan2017-09-033-89/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | mpv's mouse button numbering is based on X11 button numbering, which allows for an arbitrary number of buttons and includes mouse wheel input as buttons 3-6. This button numbering was used throughout the codebase and exposed in input.conf, and it was difficult to remember which physical button each number actually referred to and which referred to the scroll wheel. In practice, PC mice only have between two and five buttons and one or two scroll wheel axes, which are more or less in the same location and have more or less the same function. This allows us to use names to refer to the buttons instead of numbers, which makes input.conf syntax a lot easier to remember. It also makes the syntax robust to changes in mpv's underlying numbering. The old MOUSE_BTNx names are still understood as deprecated aliases of the named buttons. This changes both the input.conf syntax and the MP_MOUSE_BTNx symbols in the codebase, since I think both would benefit from using names over numbers, especially since some platforms don't use X11 button numbering and handle different mouse buttons in different windowing system events. This also makes the names shorter, since otherwise they would be pretty long, and it removes the high-numbered MOUSE_BTNx_DBL names, since they weren't used. Names are the same as used in Qt: https://doc.qt.io/qt-5/qt.html#MouseButton-enum
* w32_common: handle media keysJames Ross-Gowan2017-08-054-2/+19
| | | | | | | | | | | | | | | | | This was attempted before in fc9695e63b5b, but it was reverted in 1b7ce759b1f4 because it caused conflicts with other software watching the same keys (See #2041.) It seems like some PCs ship with OEM software that watches the volume keys without consuming key events and this causes them to be handled twice, once by mpv and once by the other software. In order to prevent conflicts like this, use the WM_APPCOMMAND message to handle media keys. Returning TRUE from the WM_APPCOMMAND handler should indicate to the operating system that we consumed the key event and it should not be propogated to the shell. Also, we now only listen for keys that are directly related to multimedia playback (eg. the APPCOMMAND_MEDIA_* keys.) Keys like APPCOMMAND_VOLUME_* are ignored, so they can be handled by the shell, or by other mixer software.
* input: drop deprecated "osd" commandwm42017-07-212-4/+0
| | | | | Complicated situation due to changes by GPL-only author, but also unnecessary due to newer mechanisms.
* Avoid calling close(-1)wm42017-06-291-2/+4
| | | | | | | | | | While this is perfectly OK on Unix, it causes annoying valgrind warnings, and might be otherwise confusing to others. On Windows, the runtime can actually abort the process if this is called. push.c part taken from a patch by Pedro Pombeiro.
* build: change how some OS specific source files are selectedwm42017-06-293-1/+16
| | | | | | | | | | | | | | | | | | In a bunch of cases, we emulate highly platform specific APIs on a higher level across all OSes, such as IPC, terminal, subprocess handling, and more. We have source files for each OS, and they implement all the same mpv internal API. Selecting which source file to use on an OS can be tricky, because there is partially overlapping and emulated APIs (consider Cygwin on Windows). Add a pick_first_matching_dep() function to make this slightly easier and more structured. Also add dummy backends in some cases, to deal with APIs not being available. Clarify the Windows dependency identifiers, as these are the most confusing.
* player: deprecate "osd" commandwm42017-06-231-0/+2
| | | | | | | | | | | It was extended by "seru" in 8d190244. This person could not be reached (or does not reply), and it's in the way of LGPL relicensing. Deprecate it, and mark the (probably) affected parts of the code with HAVE_GPL. To be fair, even though the osd.c parts were refactored from the original code, there's probably no copyright by seru on it. But for now play it save. The mere existence of a 3rd OSD level is certainly not copyrightable, so you still can set osd-level to 3 - just that it does nothing.
* input/keycodes: change license to LGPLwm42017-06-202-16/+14
| | | | | All relevant authors have agreed. See 2e84934be7 (the mentioned person has replied and agreed now).
* input: mention GPL exceptions in license headerwm42017-06-201-0/+2
| | | | (Just to make our HAVE_GPL business explicit.)
* input: change license to LGPLwm42017-06-196-42/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cehoyos adds the step_property command in 7a71da01d, and it could be argued that copyright of this still applies to the later add/cycle commands (a668ae0ff90c4). While I'm not sure if this is really the case, stay conservative for now and mark these commands as GPL-only. Mark the command.c code too, although that is not being relicensed yet. I'm leaving the MP_CMD_* enum items, as they are obviously different. In commit 116ca0c7682, "veal" (essentially an anonymous author) adds an "osd_show_property_text" command (well, the commit message says "based on" that person's code, so it's not clear how much is from him or from albeu, who agreed to LGPL). This was later merged again with the "osd_show_text" command, and then all original code was removed in commit 58cc0f637f, so I claim that no copyright applies anymore. (Though technically the input.conf addition still might be copyrighted, so I'm just dropping it to get rid of the thought.) "kiriuja" added 2f376d1b39 (sub_load etc.) and be54f4813 (switch_audio). The latter is gone. I would argue that the former is fully rewritten with commits b7052b431c9 and 0f155921b0. But like in the step_property case, I will be overly conservative for now, and mark them as GPL-only, as this is potentially shaky and should be thought through first. (Not bothering with the command define/enum in the header, as it will be unused in LGPL mode anyway.) keycodes.c/h can be GPL, except for commit 2b1f95dcc2f8, which is a patch by someone who wasn't asked yet. Before doing something radical, I will wait for a reply.
* ipc-unix: don’t truncate the message on EAGAINSebastian Reuße2017-05-241-4/+1
| | | | Fixes #4452.
* command: use scale_units to add/cycle integer propertiesJames Ross-Gowan2017-05-123-1/+5
| | | | | | | | | | | | | | | This adds check_property_scalable, which returns true if the property is backed by a floating-point number. When the add or cycle commands operate on these properties, they can benefit from the fractional scale value in cmd->scale. When the property is not backed by a floating-point number, cmd->scale_units is used instead, so for axis events, the property is only incrmented when the user scrolls one full unit. This solution isn't perfect, because in some cases integer-backed properties could benefit from accurate scrolling. For example, if an axis is bound to "cycle audio 5", the cycle command could be made to change the audio track by one when the user scrolls 1/5th of a unit, though this behaviour would require more changes to the options system.
* input: pre-process MP_AXIS_* inputJames Ross-Gowan2017-05-121-6/+101
| | | | | | | | | | | | | | | | | | | | | This adds some logic for pre-processing MP_AXIS_* events before the corresponding input command is generated. Firstly, the events are filtered. A lot of touchpad drivers and operating systems don't seem to filter axis events, which makes it difficult to use the verical axis (MP_AXIS_UP/MP_AXIS_DOWN) without accidentally triggering commands bound to the horizontal axis (MP_AXIS_LEFT/MP_AXIS_RIGHT) and vice-versa. To fix this, a small deadzone is used. When one axis breaks out of the deadzone, events on the other axis are ignored until the user stops scrolling (determined by a timer.) Secondly, the scale_units value is determined, which is the integer number of "units" the user has scrolled, as opposed to scale, which is the fractional number of units. It's determed by accumulating the fractional scale values. If an axis is bound to a "non-scalable" command that doesn't understand fractional units, interpret_key() will queue that many commands, each with scale = 1.0.
* command: mark some commands as "scalable"James Ross-Gowan2017-05-122-2/+14
| | | | | | | | | | Scalable commands (seek, cycle and add) understand the cmd->scale parameter and will "scale" their action accordingly, for example, a seek with scale = 0.5 will only seek half the specified amount and a seek with scale = 2.0 will seek twice as much. Mark these commands so in the next commit, input.c will be able to synthesize input with cmd->scale = 1 for non-scalable commands.
* input: add MP_KEY_IS_AXIS and treat MP_AXIS_* as mouse eventsJames Ross-Gowan2017-05-121-2/+8
| | | | | MP_AXIS_* events are semantically equivalent to scroll button events (eg. MP_MOUSE_BTN{3,4,5,6}). They depend on the mouse position.
* ipc: raise json nesting limitwm42017-05-031-2/+2
| | | | Fixes the issue pointed out in #4394.
* input: add "async" flagwm42017-04-012-0/+2
| | | | | | | | | | | Obviously, this has no effect on commands which do not support this explicitly. A later commit will enable this for screenshots. Also add some wording on mpv_command_async(), which has nothing to do with this. Having a more elegant, unified behavior would be nice. But the API function was not created for this - it's merely for running commands _synchronously_ on the core, but without blocking the client API caller (if the API user consistently uses only async functions).
* osx: fix key input in certain circumstancesAkemi2017-03-261-8/+0
| | | | | | | | | | | | | for a reason i can just assume some key events can vanish from the event chain and mpv seems unresponsive. after quite some testing i could confirm that the events are present at the first entry point of the event chain, the sendEvent method of the Application, and that they vanish at a point afterwards. now we use that entry point to grab keyDown and keyUp events. we also stop propagating those key events to prevent the no key input' error sound. if we ever need the key events somewhere down the event chain we need to start propagating them again. though this is not necessary currently.
* command: add expand-text command to property-expand a stringAvi Halachmi (:avih)2017-03-262-0/+2
|
* player: restructure cancel callbackwm42017-01-182-6/+7
| | | | | | | | | | | | As preparation for file prefetching, we basically have to get rid of using mpctx->playback_abort for the main demuxer (i.e. the thing that can be prefetched). It can't be changed on a running demuxer, and always using the same cancel handle would either mean aborting playback would also abort prefetching, or that playback can't be aborted anymore. Make this more flexible with some refactoring. Thi is a quite shitty solution if you ask me, but YOLO.
* client API: turn mpv_suspend() and mpv_resume() into stubswm42016-11-221-6/+0
| | | | | | | | | | | As threatened by the API changes document. This commit also removes or stubs equivalent calls in IPC and Lua scripting. The stubs are left to maintain ABI compatibility. The semantics of the API functions have been close enough to doing nothing that this probably won't even break existing API users. Probably.
* ipc: log when listening to IPC socketwm42016-09-292-0/+4
| | | | Fixes #3598.
* command: add a load-script commandwm42016-09-222-0/+4
| | | | | | | The intention is to give libmpv users as much flexibility to load scripts as using mpv from CLI, but without restricting libmpv users from having to decide everything on creation time, or having to go through hacks like recreating the libmpv context to update state.
* options: make input options generally runtime-settablewm42016-09-212-54/+74
|
* player: kill associated OSD and key bindings when removing a scriptwm42016-09-202-2/+28
| | | | | The former was done already for Lua scripts, but move it to the generic code.
* command: add an apply-profile commandwm42016-09-172-0/+4
| | | | | This will actually update all associated options (which is trivial now with the recent changes).
* player: use better way to wait for input and dispatching commandswm42016-09-162-34/+19
| | | | | | | | | | | | | | | | | | | Instead of using input_ctx for waiting, use the dispatch queue directly. One big change is that the dispatch queue will just process commands that come in (e.g. from client API) without returning. This should reduce unnecessary playloop excutions (which is good since the playloop got a bit fat from rechecking a lot of conditions every iteration). Since this doesn't force a new playloop iteration on every access, this has to be enforced manually in some cases. Normal input (via terminal or VO window) still wakes up the playloop every time, though that's not too important. It makes testing this harder, though. If there are missing wakeup calls, it will be noticed only when using the client API in some form. At this point we could probably use a normal lock instead of the dispatch queue stuff.