summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* 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 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