| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
The former was done already for Lua scripts, but move it to the generic
code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
Apparently useful for window embedding.
Fixes #2750.
|
| |
|
|
| |
This change helps avoiding conflict with talloc.h from libtalloc.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This can be used to grab all unmapped keys.
Fixes #2612.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| | |
|
| | |
|
| |
|
|
|
| |
Wakeup FDs are not needed anymore (this code exists only for libwaio
usage by now), and 2 other functions can be made private.
|
| |
|
|
|
|
|
|
|
|
| |
Wnile it seems quite logical to me that commands use _ as word
separator, while properties use -, I can't really explain the
difference, and it tends to confuse users as well. So always
prefer - as separator for everything.
Using _ still works, and will probably forever. Not doing so would
probably create too much chaos and confusion.
|
| |
|
|
| |
Prevents the OSC from showing up on start on Cocoa.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
| |
Someday I'll look through all the options and find whatever else is
missing it...
|
| |
|
|
|
|
|
|
|
|
|
| |
Why did this exist in the first place? Other than being completely
useless, this even caused some regressions in the past. For example,
there was the case of a laptop exposing its accelerometer as joystick
device, which led to extremely fun things due to the default mappings of
axis movement being mapped to seeking.
I suppose those who really want to use their joystick to control a media
player (???) can configure it as mouse device or so.
|
| |
|
|
| |
It's much easier to configure remotes as X11 input devices.
|
| |
|
|
|
|
|
| |
Add MP_KEY_MOUSE_ENTER to the ignored input if the user has disabled
mouse input. Remove one instance of code duplication, and add a
MP_KEY_IS_MOUSE_MOVE macro to summarize events that are caused by moving
the mouse.
|
| |
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closing the video window sends CLOSE_WIN, which is normally mapped to
the "quit" command. The client API normally disables all key bindings,
and closing the window does nothing. It's simply left to the application
to handle this. This is fine - an embedded window can not be destroyed
by user interaction.
But sometimes, the window might be destroyed anyway, for example because
the containing window is destroyed. If this happens, CLOSE_WIN should
better not be ignored. We can't expect client API users to handle this
specially (by providing their own input.conf), so provide some fallback
for this pseudo key binding. The "quit" command might be too intrusive
(not every client necessarily handles "unexpected" MPV_EVENT_SHUTDOWN),
but I think it's still reasonable.
|
| |
|
|
|
|
|
|
|
|
| |
If the user has LEFT/RIGHT/etc. bound in his input.conf, then these were
overriding the menu keys in dvdnav mode.
This hack works because the dvdnav crap happens to be the only user of
MP_INPUT_ON_TOP. If it finds a default key binding in the dvdnav menu
section, it will use that, instead of continuing search and possibly
finding the user key bindings meant for normal playback.
|
| |
|
|
|
|
| |
This just kept adding bindings to the input section, rather than
defining it. One bad effect was that mp.remove_key_binding() in Lua
didn't work.
|
| | |
|
| |
|
|
|
| |
If repeated framestep commands are sent, just unpause the player, instead
of playing N frames for N repeated commands.
|
| |
|
|
|
| |
Much of it is the same, but now there's the possibility to distinguish
key down/up events in the Lua API.
|
| |
|
|
|
|
|
|
|
|
| |
Otherwise, mouse button bindings added by mp.add_key_binding() would be
ignored.
It's possible that this "breaks" some older scripts using undocumented
Lua script functions, but it should be safe otherwise.
Fixes #1283.
|
| |
|
|
|
|
| |
The fact that it's a generic command prefix that is parsed even when
using the client API is a bit unclean (because this flag makes sense
for actual key-bindings only), but it's less code this way.
|
| |
|
|
|
| |
If there are several input.confs in the set of valid config paths, load
them all.
|
| |
|
|
|
|
|
|
|
|
| |
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.
Since this is not portable, we check the OS variants in waf configure.
old-configure just gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
|
| | |
|
| |
|
|
| |
Minor simplification, also drops some useless stuff.
|
| |
|
|
|
|
| |
The event monitor is used to get keyboard events when there is no window, but
since it is a global monitor to the current process, we don't want it in a
library setting.
|
| |
|
|
|
| |
Apparently we need this for Cocoa too. (The option was X11 specific in
the hope that only X11 would need this hack.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 64b7811c tried to do the "right thing" with respect to whether
keyboard input should be enabled or not. It turns out that X11 does
something stupid by design. All modern toolkits work around this native
X11 behavior, but embedding breaks these workarounds.
The only way to handle this correctly is the XEmbed protocol. It needs
to be supported by the toolkit, and probably also some mpv support. But
Qt has inconsistent support for it. In Qt 4, a X11 specific embedding
widget was needed. Qt 5.0 doesn't support it at all. Qt 5.1 apparently
supports it via QWindow, but if it really does, I couldn't get it to
work.
So add a hack instead. The new --input-x11-keyboard option controls
whether mpv should enable keyboard input on the X11 window or not. In
the command line player, it's enabled by default, but in libmpv it's
disabled.
This hack has the same problem as all previous embedding had: move the
mouse outside of the window, and you don't get keyboard input anymore.
Likewise, mpv will steal all keyboard input from the parent application
as long as the mouse is inside of the mpv window.
Also see issue #1090.
|
|
