Some keys like WHEEL_UP are "scaled" if the input source is high
resolution, like touchpad. However, sometimes it's desirable to
disable this scaling and only active the key binding in discrete
steps, such as relative keyframe seeking which interacts poorly
if the command is scaled.
This adds the nonscalable prefix to disable this scaling.
Key names are already required be UTF-8 like everything else
in mpv other than media file formats which support other encodings.
stream_skip_bom is the wrong function for this, since it also skips
UTF-16 BOM.
It has been changed in one of the iterations of the patch during review,
but bstr doesn't have to be null terminated. Fix it by adding dedicated
node_map helper.
Fixes: 1a27f3c
In general, mpv treats numpad keys as separate inputs. The +-*/ keys
however are exceptions so it's not possible to distinguish them from
non-numpad keys.
This adds keycodes corresponding to these keys so that they can be
handled differently.
I don't know if this broke anything but the the condition was inverted
as a result of the recent commit.
Fixes: 1a27f3caf7 ("input: use bstr for section name")
Resolves mixed use of bstr in internal processing and char* for storage.
Also makes faster comparision when searching for section and resolves
comparision when name contains null chars.
This makes --input-ipc-client work on Windows.
To use this feature, a parent process needs to create a connected named pipe,
wrap the server handle in a CRT fd, and then spawn mpv as a child process
with the fd as the --input-ipc-client parameter.
The process can then communicate through the client handle.
The named pipe must be created duplex with overlapped IO and inheritable
handles.
Normally, key bindings are resolved in the input section stack order.
However, mouse key bindings have a special "active mouse section" feature
(which is a section with MOUSE_MOVE bound and mouse button is down in the
section) which lets the section to be selected instead, with a fallback
to the "default" section. The intention of the feature is for mouse
dragging which should "stick" to the section where the mouse is down.
This causes a problem with scripts which bind mouse double clicks:
since double clicks are triggered on mouse down, it's resolved with the
"active mouse section" feature instead of the section stack order.
If the section which has the double click bound doesn't also have
MOUSE_MOVE bound, the "default" section will be used instead.
If it's already bound there, it will be triggered.
Fix this by not resolving double clicks on the active mouse section, which
is not the intention of the feature.
In certain situations (including but not limited to begin window dragging),
it is desired to cancel the current command completely. However, commands
which have on_updown flag set require the command to be invoked in this
situation. There is currently no way to know if the command is triggered
normally or triggered because it is dropped.
This adds a canceled state to mp_cmd which indicates this.
This adds the --input-builtin-dragging option, which allows the built-in
dragging behavior to be disabled. This allows scripts to implement custom
dragging behavior with left button down events and begin-vo-dragging
command, which could only be done for other mouse buttons before.
Currently, the built-in VO dragging conflicts with the MBTN_LEFT binding,
so the binding is activated even though the VO dragging begins. Fix this
by releasing the currently down command so that MBTN_LEFT can be bound to
a useful action (such as play/pause).
The stored mouse position mouse_vo_x/y are scaled (currently only for
vo_xv), but the position equality check compares between raw position
and scaled position.
Fix this by storing and checking the raw position instead. The raw
position is useful for the next commit.
This fixes 2 different bugs:
- mp.add_key_binding('c', ...) taking priority over the builtin g-c
binding.
This follows up 994a08f5a7 which fixed this within the same input
section. This fixes it across different input sections.
- mp.add_key_binding('g-c', ...) not taking priority over a c binding
defined in input.conf.
This happened because is_builtin of bindings added with
mp.add_key_binding is true though they're not actually builtin.
If g-p is a builtin binding and p is bound in input.conf, pressing g-p
triggers the p binding. Fix this by searching for builtin bindings that
match a longer key sequence even after a user-defined binding has been
found.
Even after changing the condition from >= to > bindings of the same key
defined later in input.conf are still preferred over earlier ones,
because bind_keys() overwrites duplicate bindings. Bindings defined by
later mp.add_key_binding calls are also still preferred.
This adds --input-touch-emulate-mouse option, which controls whether to
enable legacy touch handling where touch inputs are emulated as mouse
inputs. This establishes a primary touch point (the one with the lowest
index) as the emulated mouse position, and MBTN_LEFT up/down with the
appearance of the first touch point and the disappearance of the last
touch point.
This fixes some problems with touch handling on Wayland, for example
attempting to pinch results in a double click.
The goal of multitouch support is to interpret as little as possible:
mpv just stores the touch point information and makes the position
available for query. Does not participate in the deprecated input section
system.
The API is modeled after the common part of the touch input APIs of
Win32, X11, and Wayland, to make sure the platform-specific implementations
are as simple as possible.
mp_input_sdl_gamepad_add() calls mp_input_add_thread_src() which
already locks, so it cannot be called inside a lock.
Missed in e8b9476bf7 refactoring.
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.
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.
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.
585d8c6856 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
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.
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.
nanahi
Kacper Michajłow
llyyr
Guido Cella
sfan5
der richter
David Vaughan