summaryrefslogtreecommitdiffstats
path: root/input
Commit message (Collapse)AuthorAgeFilesLines
* input: fix deadlock in adding gamepad input srcHEADmasternanahi3 hours1-4/+6
| | | | | | | mp_input_sdl_gamepad_add() calls mp_input_add_thread_src() which already locks, so it cannot be called inside a lock. Missed in e8b9476bf706401fa0e57fb117012124264483d2 refactoring.
* input: make mp_input_queue_cmd return a meaningful valuenanahi2 days1-6/+7
| | | | | It's currently always a meaningless 1. Make it so it returns 0 is cmd is NULL. Remove the unused return value from queue_cmd.
* input: don't use recursive mutexnanahi2 days1-1/+1
| | | | | | Previous commits made sure that the lock will never be called for more than once for all public functions. Thus deadlock is impossible, so recursive mutex is unneeded and can be converted to a normal mutex.
* input: avoid unnecessary recursive locksnanahi2 days1-65/+95
| | | | | | | | | | | | | | | | | | The absense of a call hierarchy between public and private functions results in many unnecessary recursive locks: public functions require locks, which are also called by other public and private functions in this file. Fortunately, since the lock is private to this file, this situation can be avoided by establishing a call hierarchy: - Public functions must lock, and can only call private functions in this file - Private functions must not lock, and can only call private functions in this file - No function can call any public function in this file, the only exception being mp_input_wakeup and mp_input_parse_cmd. This arrangement ensures that there will be no locks more than necessary: All public function calls will lock only once, and never recursively.
* input: remove mp prefix for static functionsnanahi2 days1-11/+11
| | | | | This makes it easy to eyeball check the call hierarchy between public and private functions.
* input: fix locking of mp_input_bind_keynanahi2 days1-0/+2
| | | | | | | This is a public function, yet its access to ictx through get_bind_section is not locked. Fixes: 4614d432a8d21ab135af25a183f57efd5059bb62
* mac/apphub: migrate remaining events functionality to new AppHubder richter2024-03-241-1/+1
| | | | | | | | add new app_bridge objc file for bridging between mpv core and app functionality. replace old EventsResponder singleton with AppHub. another step to clean up all App functionality and have one central place for it.
* input: remove max active section limitnanahi2024-03-211-15/+10
| | | | | | | | | | | 585d8c6856e8eaf77c518ad4679e8c66660fc440 increased max active section limit from 5 to 50 but this obviously doesn't properly fix the problem. Input still breaks if more than 25 scripts are loaded, or if some scripts define lots of input sections. Remove the limit completely by using a dynamic array for active sections. Fixes: https://github.com/mpv-player/mpv/issues/13707
* input: raise maximum key down limit to 16nanahi2024-03-211-1/+1
| | | | | The current limit of 4 is stupidly low, and won't be future proof in case proper multi-touch support is added.
* input: centralize VO draggingnanahi2024-03-011-6/+10
| | | | | | | | | | | | | | | | | | | | | | Currently, VO dragging logic is hardcoded into each VO, where a left mouse button down event unconditionally begins dragging if the VO dragging test passes. This method is extremely unflexible as the VO has no knowledge of what is happening in the input system: while begin dragging with the second click of a doubleclick is undesired, it cannot determine whether a click is a double click or not because it's determined by the input system. The better way to do it is to handle it somewhere in the downstream consumers of the events instead, as they have more information to make this decision. The input system is the perfect place for this as the logic for checking doubleclick already exists. So just issue a begin-vo-dragging command if it detects a left mouse button down which isn't also a doubleclick in this case, and delete all hardcoded VO dragging logic in win32, x11, and wayland. Note that this solution hardcodes left mouse button down for now, but because the VO dragging is now centralized, it's possible to make more improvements, such as a deadzone mechanism to fix the conflict with MBTN_LEFT mouse bind.
* osdep/mac: make mac naming of files, folders and function consistentder richter2024-02-281-1/+1
| | | | | rename all macOS namings (osx, macosx, macOS, macos, apple) to mac, to make naming consistent.
* input: add insert-next support for drag-and-dropDavid Vaughan2024-02-262-2/+18
| | | | | | | This commit adds a DND_INSERT_NEXT action option for drag-and-drop, allows for selecting it through the --drag-and-drop=insert-next option, and adds the necessary plumbing to make that happen when something is dragged onto the player.
* input: add --input-preprocess-wheel optionnanahi2024-02-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | This adds --input-preprocess-wheel option, which can be used to control whether to preprocess received wheel events. Commit 937128697fbbef6b21e2d23a4785f1334f62b9e3 added preprocessing of wheel events to prevent the accidental scrolling of another direction when one direction is being scrolled for touchpads, which is problematic with the default wheel bindings where unrelated functions (seeking and volume) are used for the 2 directions. However, this behavior is undesirable in the following situations: - When custom wheel bindings are used so that the 2 directions are used for closely related actions, such as panning. With preprocessing, diagonal movement is impossible. - Since the wheel deadzone was introduced to prevent accidental scrolling for touchpads, this filtering provides no benefit for high resolution unidirectional mouse wheels, while causing a regression where scrolling at least 0.125 units is required to trigger the event, causing input delay. By adding this option, these two use cases are addressed.
* command: add load-input-confGuido Cella2024-02-042-0/+12
| | | | | | | | | | | | | | | | This can be used to auto reload the input configuration file, e.g. in vim: autocmd BufWritePost ~/.config/mpv/input.conf silent !echo load-input-conf %:p | socat - /tmp/mpvsocket Partially fixes #6362. Additionally this can be used as a replacement for deprecated input sections if they are ever actually removed. For example, if you want to define different bindings for images, you can load-input-conf an input.conf for images, and load the original again when switching to a video. Though currently you would have to redefine builtin bindings that were overwritten with image ones in the default input.conf.
* input: make parse_config_file return boolGuido Cella2024-02-041-3/+3
| | | | | This return value is only used to set bool config_ok in mp_input_load_config so it makes more sense to return bool.
* input: remove unused parameter from parse_config_fileGuido Cella2024-02-041-3/+3
| | | | This is unused since fb4d26e769.
* input: add value argument for mp_input_put_key_artificialsfan52023-12-172-3/+6
|
* player/command: add ability to scale overlayGraham Booker2023-12-081-1/+1
|
* input: add missing forward media keynanahi2023-12-062-5/+7
| | | | | | | | | XF86Back and XF86Forward are mostly used to navigate file and web browsers to go back/forward in history. XF86Forward isn't recognized right now, so add it. Because XF86AudioForward already takes the "FORWARD" name, rename the browse keys to GO_BACK and GO_FORWARD instead.
* input: fix double click handlingnanahi2023-12-031-0/+1
| | | | | | | | | | On practically all platforms and GUI toolkits, a triggered double click event clears the mouse input buffer so that the next click won't trigger another double click event. mpv doesn't do this, so a third click results in another double click event. Fix this by resetting the double click timer after a double click event is triggered which achieves the same effect.
* sdl_gamepad: add version check for SDL_HINT_JOYSTICK_THREADnanahi2023-11-241-0/+2
| | | | Requires SDL version 2.0.14.
* win32: don't jump over variable init with gotoKacper Michajłow2023-11-181-1/+2
| | | | Those variables are accessed after jump.
* mp_thread: add win32 implementationKacper Michajłow2023-11-051-1/+0
|
* mp_thread: prefer tracking threads with idKacper Michajłow2023-11-053-5/+3
| | | | | | | | | | | | | | This change essentially removes mp_thread_self() and instead add mp_thread_id to track threads and have ability to query current thread id during runtime. This will be useful for upcoming win32 implementation, where accessing thread handle is different than on pthreads. Greatly reduces complexity. Otherweis locked map of tid <-> handle is required which is completely unnecessary for all mpv use-cases. Note that this is the mp_thread_id, not to confuse with system tid. For example on threads-posix implementation it is simply pthread_t.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-054-41/+42
|
* mp_threads: rename threads for consistent naming across all of themKacper Michajłow2023-10-273-5/+9
| | | | | | | | I'd like some names to be more descriptive, but to work with 15 chars limit we have to make some sacrifice. Also because of the limit, remove the `mpv/` prefix and prioritize actuall thread name.
* input: convert autorepeat timing to nanosecondsDudemanguy2023-10-161-7/+7
|
* win32/pthread: define _POSIX_TIMERS to notify they are not supportedKacper Michajłow2023-09-291-1/+1
|
* options: remove ancient option fallbacks/deprecationDudemanguy2023-09-211-4/+0
| | | | | | | | | | | | | We've got an ungodly amount of OPT_REPLACED and OPT_REMOVED sitting around in the code. This is harmless, but the vast majority of these are ancient. 26f4f18c0629998a9b91e94722d166866d8b80a3 is the last commit that touched the majority of these and of course that only changed how options were declared so all of this stuff was deprecated even before that. No use in keeping these, so just delete them all. As an aside, there was actually a cocoa_opts but it had only a single option which was replaced by something else and empty otherwise. So that entire thing was just simply removed. OPT_REPLACED/OPT_REMOVED declarations that were added in 0.35 or later were kept as is.
* sdl_gamepad: fix button detection on modern controllersDeadSix272023-09-211-0/+2
| | | | Needed to get the Xbox Series X Controller working fully.
* input: add missing keypad key definesChristoph Heinrich2023-08-252-0/+16
| | | | | | | | So far all the keypad keys except for `0` and `,` mapped to the same MP_KEY_* independent of numlock state, even though different key codes are received. Now all the alternative functions map to appropriate MP_KEY_* defines, with missing ones added.
* input: add new keys: Back, Tools, ZoomIn, ZoomOutJames Cuzella2023-08-232-0/+8
| | | | | | | | | | | | | | | | | These were the only keys missing to support mapping all keycodes on a [popular RF Remote][1] used with Linux HTPC apps. Note that X11/XWayland + xkbcomp still warns about keycodes > 255, due to the 8-bit limit in Xorg but `mpv` on Wayland is able to handle these. For X11 users, there are [a couple options][2]: - [Gianni Ceccarelli's patched `xf86-input-evdev`][3] - [Use udev hwdb to map scancodes to keycodes][4] [1]: https://www.mythtv.org/wiki/Air_mouse_rf_remote [2]: https://unix.stackexchange.com/a/436233/7688 [3]: https://www.thenautilus.net/SW/xf86-input-evdev/ [4]: https://wiki.archlinux.org/title/Map_scancodes_to_keycodes
* build: remove outdated generated directoryDudemanguy2023-07-312-1/+21
| | | | | | | | | | | | | | | | This only existed as essentially a workaround for meson's behavior and to maintain compatibility with the waf build. Since waf put everything in a generated subdirectory, we had to put make a subdirectory called "generated" in the source for meson so stuff could go to the right place. Well now we don't need to do that anymore. Move the meson.build files around so they go in the appropriate place in the subdirectory of the source tree and change the paths of the headers accordingly. A couple of important things to note. 1. mpv.com now gets made in build/player/mpv.com (necessary because of a meson limitation) 2. The macos icon generation path is shortened to TOOLS/osxbundle/icon.icns.inc.
* json: unify json_parse depth to MAX_JSON_DEPTH=50cvzi2023-07-081-1/+1
|
* options: transition commands from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-212-0/+2
|
* options: transition options from OPT_FLAG to OPT_BOOLChristoph Heinrich2023-02-211-27/+25
| | | | | | c78482045444c488bb7948305d583a55d17cd236 introduced a bool option type as a replacement for the flag type, but didn't actually transition and remove the flag type because it would have been too much mundane work.
* input: remove unused struct memberChristoph Heinrich2023-02-211-1/+0
|
* various: drop unused #include "config.h"Thomas Weißschuh2023-02-203-6/+0
| | | | | | Most sources don't need config.h. The inclusion only leads to lots of unneeded recompilation if the configuration is changed.
* various: replace abort() with MP_ASSERT_UNREACHABLE() where appropriatesfan52023-01-121-1/+1
| | | | | | | | In debug mode the macro causes an assertion failure. In release mode it works differently and tells the compiler that it can assume the codepath will never execute. For this reason I was conversative in replacing it, e.g. in mpv-internal code that exhausts all valid values of an enum or when a condition is clear from directly preceding code.
* input: add function keys F13-F24Thomas Weißschuh2022-09-021-0/+12
|
* input: new option: --no-input-builtin-bindingsAvi Halachmi (:avih)2021-10-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is similar to [no-]input-default-bindings, but affects only builtin bindings (while input-default-bindings affects anything which config files can override, like scripting mp.add_key_binding). Arguably, this is what input-default-binding should have always done, however, it does not. The reason we add a new option rather than repurpose/modify the existing option is that it behaves differently enough to raise concerns that it will break some use cases for existing users: - The new option is only applied once on startup, while input-default-bindings can be modified effectively at runtime. - They affects different sets of bindings, and it's possible that the set of input-default-bindings is useful enough to keep. Implementation-wise, both options are trivial, so keeping one or the other or both doesn't affect code complexity. It could be argued that it would be useful to make the new option also effective for runtime changes, however, this opens a can of worms of how the bindings are stored beyond the initial setup. TL;DR: it's impossible to differentiate correctly at runtime between builtin bindings, and those added with mp.add_key_bindings. The gist is that technically mpv needs/uses two binding "classes": - weak/builtin bindings - lower priority than config files. - "user" bindings - config files and "forced" runtime bindings. input-default-bindings affects the first class trivially, but input-builtin-bindings would not be able split this class further at runtime without meaningful changes to a lot of delicate code. So a new option it is. It should be useful to some libmpv clients (players) which want to disable mpv's builtin bindings without breaking mp.add_key_bindings for scripts. Fixes #8809 (again. the previous fix 8edfe70b only improved the docs, while now we're actually making the requested behavior possible)
* command: don't hardcode commands list to be repeatableAvi Halachmi (:avih)2021-08-171-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, a list of commands was always considered repeatable. This behavior was added at 6710527a (and moved around since then), in order to fix #807 (impossible to make a repeatable list). The problem was that a list doesn't have the normal repeatability flags and so it was never repeatable, so it was hardcoded to be repeatable instead. Presumably it was deemed good enough. However, this made it impossible to have a non-repeatable list. This commit changes the behavior so that a list repeatability is that of the first command at the list. This way, any list can be made either repeatable or non-repeatable using the following idiom (e.g. at input.conf), based on the fact that the "ignore" command is not repeatable by default: x ignore; cmd1...; cmd2... # non-repeatable y repeatable ignore; cmd1...; cmd2... # repeatable Fixes #7841
* input: arguments quoting: support single-quotesAvi Halachmi (:avih)2021-07-301-1/+11
| | | | | | | | | | | | | | | | | | | Users expect single quotes to work when the value includes literal backslashes or double-quotes (or as general quoting like in shell). The updated docs also include some previously-missing notes: - newline is only supported in double quotes. - adjacent (quoted) arguments don't join into one. Supporting mixed quoting (adjacent quoted strings) would make mpv's parsing more complete, but would require delicate effort of larger scope, for two reasons: - We'd need to also support escaping outside of quotes and do our best about backward compatibility. - The parsed value can either be a substring of the input or a newly-allocated string, which would be delicate when joining. Not critical to add right now.
* input: argument custom quotes: use ` instead of !Avi Halachmi (:avih)2021-07-301-2/+2
| | | | | | | | | | | Custom quotes were added in 4f129a3e and began with !, however, this required quoting "!reverse" (used for the cycle-values command), which is inconvenient, and was not taken into account when ! was chosen for custom quotes. Also, ` is more natural for quoting than !. This does break backward compatibility with the earlier form of custom quotes, but at least we didn't make a release yet since custom quotes were added (the last release - 0.33[.1] doesn't support it).
* input.conf syntax: support custom quotes !XstringX!Avi Halachmi (:avih)2020-12-311-0/+13
| | | | | | | | | | Where X is any ASCII char chosen by the user. An argument is only interpreted as custom-quoted if it starts with '!' and the line doesn't end right after it. Custom quotes don't interpret backslash-escape. This change only affects command arguments which mpv parses (not array commands), and not tokens before the arguments (where applicable - key name, input section, command prefixes, command name).
* command: mouse-pos property: add field "hover"Avi Halachmi (:avih)2020-11-162-3/+10
| | | | | | | | | | | | | | | | | | | | | Add a third field: "hover", which is updated from input.c after input keys MP_KEY_MOUSE_LEAVE and MP_KEY_MOUSE_ENTER - which are typically sent by the VO. It's part of mouse-pos and not a new property because it's highly tied to mouse-pos - it makes x/y invalid while the cursor doesn't hover the window. Unike mouse-move, no dummy command was generated, so we add dummy command in order for observer notification to work even while nothing is bound. Like mouse-pos, clients could not detect whether the mouse pointer hovers the window because the OSC force-binds the MOUSE_LEAVE key, and now they can using the hover field. The lua mp.get_mouse_pos() wrapper still returns only x, y because that's what osc.lua needs. Other clients can simply read the property.
* build: change filenames of generated fileswm42020-06-041-1/+1
| | | | Force them into a more consistent naming schema.
* ipc: mark client sockets as CLOEXECwm42020-05-151-0/+2
| | | | | I suppose it would have left the socket open if the client closed its FD.
* command: add input-key-list propertywm42020-05-142-0/+11
| | | | Fixes: #7698
* ipc: exit client if the FD is invalidwm42020-05-141-1/+1
| | | | | | | This does not normally happen. But since the --input-ipc-client option can pass in raw FDs, it's probably a good thing in the interest of making mistakes obvious. Without this, it just burned a core on invalid FDs (poll() always returned immediately).
* ipc: make --input-ipc-client terminate player on connection closewm42020-05-141-1/+9
| | | | | | | | As discussed in the referenced issue. This is quite a behavior change, bit since this option is new, and not included in any releases yet, I think it's OK. Fixes: #7648
* ipc: add --input-ipc-client optionwm42020-04-091-4/+20
| | | | | | | | | While --input-file was removed for justified reasons, wanting to pass down socket FDs this way is legitimate, useful, and easy to implement. One odd thing is that Fixes: #7592
* input: remove deprecated --input-file optionwm42020-03-284-166/+0
| | | | | This was deprecated 2 releases ago. The deprecation changelog entry says that there are no plans to remove it short-term, but I guess I lied.
* ipc: fix recently added memory leakwm42020-03-271-1/+3
| | | | Sucks.
* client API, lua, ipc: unify event struct returnwm42020-03-211-99/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both Lua and the JSON IPC code need to convert the mpv_event struct (and everything it points to) to Lua tables or JSON. I was getting sick of having to make the same changes to Lua and IPC. Do what has been done everywhere else, and let the core handle this by going through mpv_node (which is supposed to serve both Lua tables and JSON, and potentially other scripting language backends). Expose it as new libmpv API function. The new API is still a bit "rough" and support for other event types might be added in the future. This silently adds support for the playlist_entry_id fields to both Lua and JSON IPC. There is a small API change for Lua; I don't think this matters, so I didn't care about compatibility. The new code in client.c is mashed up from the Lua and the IPC code. The manpage additions are moved from the Lua docs, and made slightly more "general". Some danger for unintended regressions both in Lua and IPC. Also damn these node functions suck, expect crashes due to UB. Not sure why this became more code instead of less compared to before (according to the diff stat), even though some code duplication across Lua and IPC was removed. Software development sucks.
* options: change option macros and all option declarationswm42020-03-182-20/+18
| | | | | | | | | | | | | | | | | | | | | | |