summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* 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 the one used by mpv.
* ipc: add Windows implementation with named pipesJames Ross-Gowan2016-03-234-427/+878
| | | | | | | | | | | | | | | This implements the JSON IPC protocol with named pipes, which are probably the closest Windows equivalent to Unix domain sockets in terms of functionality. Like with Unix sockets, this will allow mpv to listen for IPC connections and handle multiple IPC clients at once. A few cross platform libraries and frameworks (Qt, node.js) use named pipes for IPC on Windows and Unix sockets on Linux and Unix, so hopefully this will ease the creation of portable JSON IPC clients. Unlike the Unix implementation, this doesn't share code with --input-file, meaning --input-file on Windows won't understand JSON commands (yet.) Sharing code and removing the separate implementation in pipe-win32.c is definitely a possible future improvement.
* input/event.h: add include guardwm42016-03-151-0/+4
|
* input: accept plain text for drag&dropwm42016-03-151-0/+7
| | | | | This will work for the X11 backend. It could be easily extended to Wayland too, maybe.
* x11, input: move mime type drag&drop negotiation to common codewm42016-03-152-2/+15
| | | | | | | | | | | | | Drag&drop mechanisms typically support multiple types for the drop data. Move most of the logic which types are accepted and preferred to event.c, where the data is also interpreted. (Maybe sorting the types by assigning scores is over-engineered, since they're already sorted by preference, but it's actually not much more code.) Not very interesting/meaningful yet, but preparation for the next commit.
* ipc: fix uninitialized fieldwm42016-02-121-1/+1
| | | | | | | The sockaddr_un.sun_len field was not initialized. It seems our API use is correct by simply making sure it's 0. Fixes CID 1350075.
* input: ignore --input-cursor for events injected by input commandswm42016-02-042-7/+27
| | | | | | Apparently useful for window embedding. Fixes #2750.
* command: add af-command commandwm42016-01-222-0/+2
| | | | Similar to vf-command. Requested. Untested.
* command: add vf-command commandwm42016-01-222-0/+2
|
* Change 3 more files to LGPLwm42016-01-201-7/+7
|
* Relicense some non-MPlayer source files to LGPL 2.1 or laterwm42016-01-192-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This covers source files which were added in mplayer2 and mpv times only, and where all code is covered by LGPL relicensing agreements. There are probably more files to which this applies, but I'm being conservative here. A file named ao_sdl.c exists in MPlayer too, but the mpv one is a complete rewrite, and was added some time after the original ao_sdl.c was removed. The same applies to vo_sdl.c, for which the SDL2 API is radically different in addition (MPlayer supports SDL 1.2 only). common.c contains only code written by me. But common.h is a strange case: although it originally was named mp_common.h and exists in MPlayer too, by now it contains only definitions written by uau and me. The exceptions are the CONTROL_ defines - thus not changing the license of common.h yet. codec_tags.c contained once large tables generated from MPlayer's codecs.conf, but all of these tables were removed. From demux_playlist.c I'm removing a code fragment from someone who was not asked; this probably could be done later (see commit 15dccc37). misc.c is a bit complicated to reason about (it was split off mplayer.c and thus contains random functions out of this file), but actually all functions have been added post-MPlayer. Except get_relative_time(), which was written by uau, but looks similar to 3 different versions of something similar in each of the Unix/win32/OSX timer source files. I'm not sure what that means in regards to copyright, so I've just moved it into another still-GPL source file for now. screenshot.c once had some minor parts of MPlayer's vf_screenshot.c, but they're all gone.
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* demux: remove weird tripple-buffering for the sh_stream listwm42015-12-231-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step.
* input: add a catch-all "unmapped" commandwm42015-12-233-1/+8
| | | | | | This can be used to grab all unmapped keys. Fixes #2612.
* input: add key name to script-binding command responsewm42015-12-233-3/+4
| | | | | | | | | | | | | | | | The "script-binding" command is used by the Lua scripting wrapper to register key bindings on the fly. It's also the only way to get fine- grained information about key events (such as separate key up/down events). This information is sent via a "key-binding" message when the state of a key changes. Extend it to send name of the mapped key itself. Previously, it was assumed that the user just uses an unique identifier for the binding's name, so it wasn't needed. With this change, a user can map exactly the same command to multiple keys, which is useful especially with the next commit. Part of #2612.
* win32: input: use Vista CancelIoExJames Ross-Gowan2015-12-202-60/+65
| | | | | | | | | | | | | | | | | libwaio was added due to the complete inability to cancel synchronous I/O cleanly using the public Windows API in Windows XP. Even calling TerminateThread on the thread performing I/O was a bad solution, because the TerminateThread function in XP would leak the thread's stack. In Vista and up, however, this is no longer a problem. CancelIoEx can cancel synchronous I/O running on other threads, allowing the thread to exit cleanly, so replace libwaio usage with native Vista API functions. It should be noted that this change also removes the hack added in 8a27025 for preventing a deadlock that only seemed to happen in Windows XP. KB2009703 says that Vista and up are not affected by this, due to a change in the implementation of GetFileType, so the hack should not be needed anymore.
* input: rename recently added HALF_SPACEwm42015-10-211-1/+1
| | | | | | There was a complaint that the naming is inaccurate. That's probably right. Just use the official name instead, which is a bit clunky, but surely correct.
* input: add key name for U+3000 IDEOGRAPHIC SPACEwm42015-10-211-0/+1
| | | | | | | Deserves its own name, because just like SPACE it's a printable character, but invisible. Fixes #2349... I think.
* player: rename and move find_subfiles.cwm42015-09-201-1/+1
| | | | | | This was in sub/, because the code used to be specific to subtitles. It was extended to automatically load external audio files too, and moving the file and renaming it was long overdue.
* command: make "add <property> 0" not change the valuewm42015-09-102-1/+8
| | | | | | | | | | | | | | | The value 0 was treated specially, and effectively forced the increment to 1. Interestingly, passing 0 or no value also does not include the scale (from touchpads etc.), but this is probably an accidental behavior that was never intentionally added. Simplify it and make the default increment 1. 0 now means what it should: the value will not be changed. This is not particularly useful, but on the other hand there is no need for surprising and unintuitive semantics. OARG_CYCLEDIR() failed to apply the default value, because m_option_type_cycle_dir was missing a copy handler - add this too.
* options: fix --no-configwm42015-09-051-1/+1
| | | | | | | | | | | | | | | | | | This was completely broken. It was checked manually in some config loading paths, so it appeared to work. But the intention was always to completely disable reading from the normal config dir. This logic was broken in commit 2263f37d. The manual checks are actually redundant, and are not needed if --no-config is implemented properly - remove them. Additionally, the change to load the libmpv defaults from an embedded profile also failed to set "config=no". The option is marked as not being settable by a config file, and the libmpv default profile is parsed as a config file, so this option was rejected. Fix it by removing the CONF_NOCFG flag. (Alternatively, m_config_set_profile() could be changed not to set the "config file" flag by default, but I'm not bothering with this.)
* input: add append argument to file drop eventKevin Mitchell2015-08-302-7/+15
| | | | | | This puts in place the machinery to merely append dropped file to the playlist instead of replacing the existing playlist. In this commit, all front-ends set this to false preserving the existing behaviour.
* lua: implement input_enable_section/input_disable_section via commandswm42015-08-061-2/+4
| | | |