summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* client API: declare mpv_suspend/mpv_resume deprecatedwm42016-09-162-10/+2
| | | | | | | They're useless, and I have no idea what they're actually supposed to do (wrt. pending input processing changes). Also remove their implicit uses from the IPC handlers.
* client API: remove SIGPIPE overriding codewm42016-09-151-0/+6
| | | | | | | This workaround prevented that libmpv users could accidentally crash when the SIGPIPE signal was triggered by FFmpeg's OpenSSL/GnuTLS usage. But it also modifies the global signal handler state, so remove it now that this workaround is not required anymore.
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* input, demux_tv: remove some older option access methodswm42016-09-061-5/+6
|
* command: remove vo-cmdlinewm42016-09-022-5/+0
| | | | | | With the recent vo_opengl changes it doesn't do anything anymore. I don't think a deprecation period is necessary, because the command was always marked as experimental.
* input: use OPT_REPLACED for an old option aliaswm42016-08-311-1/+1
|
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301-2/+1
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* Use - as command-name separator everywhereTimotej Lazar2016-07-142-2/+2
| | | | | | | Old-style commands using _ as separator (e.g. show_progress) were still used in some places, including documentation and configuration files. This commit updates all such instances to the new style (show-progress) so that commands are easier to find in the manual.
* input: remove redundant log messagewm42016-07-041-4/+1
|
* build: silence -Wunused-resultNiklas Haas2016-06-071-2/+2
| | | | | | | | For clang, it's enough to just put (void) around usages we are intentionally ignoring the result of. Since GCC does not seem to want to respect this decision, we are forced to disable the warning globally.
* input: fix parsing multiple input command prefixesPhilip Sequeira2016-04-171-1/+0
|
* input: do not force double-click emulation for artificial commandswm42016-03-261-1/+1
| | | | | | | | | E.g. "mouse 100 100 1 double" did not actually process the double-click, because double-click emulation is on by default. So the user would have to send two successive clicks instead. This is probably not expected, so disable this weird logic for artificial input. Fixes #2899.
* ipc-win: restrict read access to the IPC pipeJames Ross-Gowan2016-03-251-2/+96
| | | | | | | | | | | | | | | The default security descriptor for named pipes in Windows allows the pipe to be opened for read access by the Everyone group and Anonymous account, as well as low-integrity processes (like web browser renderer processes.) This does not allow commands to be ran, but it does allow events to be received. I don't think any sensitive data is exposed by events, but that may not always be the case and Lua plugins might change this, since they can broadcast their own events with script-message. To be safe, this commit sets a custom security descriptor on the named pipe which only allows access from processes running under the same user account with an integrity level greater than or equal to