Commit Graph

573 Commits

Author SHA1 Message Date
Avi Halachmi (:avih) 58004ea2ef command: mouse-pos property: add field "hover"
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.
2020-11-16 20:29:58 +02:00
wm4 07b0c18bad build: change filenames of generated files
Force them into a more consistent naming schema.
2020-06-04 16:59:05 +02:00
wm4 b8daef5d8b input: remove deprecated --input-file option
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.
2020-03-28 00:41:38 +01:00
wm4 26f4f18c06 options: change option macros and all option declarations
Change all OPT_* macros such that they don't define the entire m_option
initializer, and instead expand only to a part of it, which sets certain
fields. This requires changing almost every option declaration, because
they all use these macros. A declaration now always starts with

   {"name", ...

followed by designated initializers only (possibly wrapped in macros).
The OPT_* macros now initialize the .offset and .type fields only,
sometimes also .priv and others.

I think this change makes the option macros less tricky. The old code
had to stuff everything into macro arguments (and attempted to allow
setting arbitrary fields by letting the user pass designated
initializers in the vararg parts). Some of this was made messy due to
C99 and C11 not allowing 0-sized varargs with ',' removal. It's also
possible that this change is pointless, other than cosmetic preferences.

Not too happy about some things. For example, the OPT_CHOICE()
indentation I applied looks a bit ugly.

Much of this change was done with regex search&replace, but some places
required manual editing. In particular, code in "obscure" areas (which I
didn't include in compilation) might be broken now.

In wayland_common.c the author of some option declarations confused the
flags parameter with the default value (though the default value was
also properly set below). I fixed this with this change.
2020-03-18 19:52:01 +01:00
wm4 1cb9e7efb8 stream, demux: redo origin policy thing
mpv has a very weak and very annoying policy that determines whether a
playlist should be used or not. For example, if you play a remote
playlist, you usually don't want it to be able to read local filesystem
entries. (Although for a media player the impact is small I guess.)

It's weak and annoying as in that it does not prevent certain cases
which could be interpreted as bad in some cases, such as allowing
playlists on the local filesystem to reference remote URLs. It probably
barely makes sense, but we just want to exclude some other "definitely
not a good idea" things, all while playlists generally just work, so
whatever.

The policy is:
- from the command line anything is played
- local playlists can reference anything except "unsafe" streams
  ("unsafe" means special stream inputs like libavfilter graphs)
- remote playlists can reference only remote URLs
- things like "memory://" and archives are "transparent" to this

This commit does... something. It replaces the weird stream flags with a
slightly clearer "origin" value, which is now consequently passed down
and used everywhere. It fixes some deviations from the described policy.

I wanted to force archives to reference only content within them, but
this would probably have been more complicated (or required different
abstractions), and I'm too lazy to figure it out, so archives are now
"transparent" (playlists within archives behave the same outside).

There may be a lot of bugs in this.

This is unfortunately a very noisy commit because:
- every stream open call now needs to pass the origin
- so does every demuxer open call (=> params param. gets mandatory)
- most stream were changed to provide the "origin" value
- the origin value needed to be passed along in a lot of places
- I was too lazy to split the commit

Fixes: #7274
2019-12-20 13:00:39 +01:00
der richter 8a6ee7fe94 mac: remove Apple Remote support
the Apple Remote has long been deprecated and abandoned by Apple.
current macs don't come with support for it anymore. support might be
re-added with the next commit.
2019-12-15 20:07:31 +01:00
wm4 c1acb1afe1 input: use array instead of linked list for sections
Shouldn't change behavior.
2019-11-23 15:00:48 +01:00
wm4 66a46cba89 input: remove potential minor memory leak 2019-11-23 14:14:19 +01:00
wm4 2dc6b27ee7 input: export input.conf comments ot input-bindings property
This is supposed to turn input.conf comments into inline documentation.
Whether this will be useful depends on whether there'll be a script
using this field.

This changes a small aspect of input.conf parsing fundamentally: this
attempts to strip comments/whitespace from the command string, which
will later be used to generate the command when a key binding is
executed. This should not have any negative effects, but there could be
unknown bugs. (For some reason, every command is parsed when input.conf
is parsed, but it still only stores the string for the command. I guess
that saves some minor amount of memory.)
2019-11-23 01:18:49 +01:00
wm4 f379cf0bf8 command, input: add input-bindings property
Read-only information about all bindings. Somewhat hoping someone can
make a nice GUI-like overlay thing for it, which provides information
about mapped keys.
2019-11-23 01:18:49 +01:00
wm4 6e0e39b79f input: change mp_cmd.original from bstr to cstr
No reason to have this as bstr, just makes everything more complex.

Also clear mp_cmd.sender when it's copied. Otherwise it would be a
dangling pointer. Apparently it's never set to non-NULL in this
situation, but this is cleaner anyway.
2019-11-23 01:18:49 +01:00
wm4 21f2468d67 input: add text produced by key to script key events
Particularly for "any_unicode" mappings, so they don't have to
special-case keys like '#' and ' ', which are normally mapped to
symbolic names for input.conf reasons. (Though admittedly, this is a
pretty minor thing, since API users could map these manually.)
2019-11-22 01:15:08 +01:00
wm4 0a6c09b96f input: introduce a pseudo key name that grabs all text input
The intended target for this is the mpv.repl script, which manually
added every single ASCII key as a separate key binding. This provides a
simpler mechanism, that will catch any kind of text input.

Due to its special nature, explicitly do not give a guarantee for
compatibility; thus the warning in input.rst.
2019-11-22 01:15:08 +01:00
wm4 a098e98198 input: fix ineffective mp_msg_test call
This was supposed not to go through key lookup if the message wasn't
going to be output, but for whatever reason the log levels were
mismatched.
2019-11-22 01:15:07 +01:00
wm4 4cae192377 options: remove M_OPT_FIXED
Options marked with this flag were changed to strictly read-only after
initialization (mpv_initialize() in the client API, after option parsing
and config file loading with the CLI player).

This used to be necessary, because there was a single option struct that
could be accessed by multiple threads. For example, --config-dir sets
MPOpts.force_configdir, which was read whenever anything accessed the
mpv config dir (which could be on different threads, e.g. font
initialization tries to lookup fonts.conf from an arbitrary thread).

This isn't needed anymore, because threads now access these in a thread
safe way. In the case of --config-dir, the path is actually just copied
on init.

This M_OPT_FIXED mechanism is thus not strictly needed anymore. It still
prevents writing to some options that cannot take effect at runtime, but
even that can be dropped. In general, all mpv options can be changed any
time at runtime, even if they never take effect, and there's no need to
make an exception for a very low number of options. So just get rid of
it.
2019-11-10 23:49:23 +01:00
wm4 6d92e55502 Replace uses of FFMIN/MAX with MPMIN/MAX
And remove libavutil includes where possible.
2019-10-31 11:24:20 +01:00
wm4 4a82349900 input: disable gamepad code by default
Enabling this by default probably causes a number of issues, such as
breaking vo_sdl, or reacting to various input devices while the window
is not focused. It's also pretty obscure, or at least new. Disable it by
default.
2019-10-25 21:54:35 +02:00
Stefano Pigozzi 899e0bd16b input: add gamepad support through SDL2
The code is very basic:

- only handles gamepads, could be extended for generic joysticks in the
  future.
- only has button mappings for controllers natively supported by SDL2.
  I heard more can be added through env vars, there's also ways to load
  mappings from text files, but I'd rather not go there yet. Common ones
  like Dualshock are supported natively.
- analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an
  activation threshold.
- only supports one gamepad at a time. the feature is intented to use
  gamepads as evolved remote controls, not play multiplayer games in mpv :)
2019-10-23 09:40:30 +02:00
Dudemanguy911 4614d432a8 input: add keybind command 2019-09-21 16:58:14 +00:00
wm4 f8ab59eacd player: get rid of mpv_global.opts
This was always a legacy thing. Remove it by applying an orgy of
mp_get_config_group() calls, and sometimes m_config_cache_alloc() or
mp_read_option_raw().

win32 changes untested.
2018-05-24 19:56:35 +02:00
wm4 b3968ecf05 input: remove now unused "abort command" and cancel infrastructure
The previous commit removed all uses.
2018-05-24 19:56:35 +02:00
wm4 88498bcc92 input: rename weirdly named function 2018-05-03 01:20:01 +03:00
wm4 76d8683e2e input: rename cmd_parse.h to cmd.h 2018-05-03 01:20:01 +03:00
wm4 e8b073584d input: remove some explicit uses of command IDs
The plan is to remove the command ID enum. This will happen by replacing
the big switch statement in command.c with dispatching to per-command
callbacks. As preparation, remove uses of the command IDs outside of the
actual dispatching mechanism.

Also remove some instances of checking cmd->def for NULL. We now require
this always to be set.
2018-05-03 01:20:01 +03:00
wm4 a702cff794 input: raise log level of some noisy messages
Same as the commit before this.
2018-04-29 02:21:32 +03:00
Niklas Haas ba1943ac00 msg: reinterpret a bunch of message levels
I've decided that MP_TRACE means “noisy spam per frame”, whereas
MP_DBG just means “more verbose debugging messages than MSGL_V”.
Basically, MSGL_DBG shouldn't create spam per frame like it currently
does, and MSGL_V should make sense to the end-user and provide mostly
additional informational output.

MP_DBG is basically what I want to make the new default for --log-file,
so the cut-off point for MP_DBG is if we probably want to know if for
debugging purposes but the user most likely doesn't care about on the
terminal.

Also, the debug callbacks for libass and ffmpeg got bumped in their
verbosity levels slightly, because being external components they're a
bit less relevant to mpv debugging, and a bit too over-eager in what
they consider to be relevant information.

I exclusively used the "try it on my machine and remove messages from
MSGL_* until it does what I want it to" approach of refactoring, so
YMMV.
2017-12-15 22:28:47 -08:00
James Ross-Gowan 7897f79217 input: merge mouse wheel and axis keycodes
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
18a45a42d5 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.
2017-09-03 20:31:44 +10:00
James Ross-Gowan 957e9a37db input: use mnemonic names for mouse buttons
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
2017-09-03 20:31:44 +10:00
James Ross-Gowan 037c7a9279 w32_common: handle media keys
This was attempted before in fc9695e63b, but it was reverted in
1b7ce759b1 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.
2017-08-05 02:38:44 +10:00
wm4 7eca787571 build: change how some OS specific source files are selected
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.
2017-06-29 10:30:16 +02:00
wm4 2e84934be7 input: change license to LGPL
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 (a668ae0ff9). 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 116ca0c768, "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 b7052b431c 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 2b1f95dcc2, which is a
patch by someone who wasn't asked yet. Before doing something radical, I
will wait for a reply.
2017-06-19 13:28:19 +02:00
James Ross-Gowan 89fd3e1d9d command: use scale_units to add/cycle integer properties
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.
2017-05-12 22:58:58 +10:00
James Ross-Gowan 937128697f input: pre-process MP_AXIS_* input
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.
2017-05-12 22:58:58 +10:00
Akemi 063ca8f0fe osx: fix key input in certain circumstances
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.
2017-03-26 20:38:26 +02:00
wm4 c54c3b6991 player: restructure cancel callback
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.
2017-01-18 17:52:05 +01:00
wm4 75d12c174f options: make input options generally runtime-settable 2016-09-21 17:35:00 +02:00
wm4 bf385e1140 player: kill associated OSD and key bindings when removing a script
The former was done already for Lua scripts, but move it to the generic
code.
2016-09-20 15:44:11 +02:00
wm4 8716c2e88f player: use better way to wait for input and dispatching commands
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.
2016-09-16 14:49:23 +02:00
wm4 9f0e7bb998 input, demux_tv: remove some older option access methods 2016-09-06 20:09:44 +02:00
wm4 f519887fe7 input: use OPT_REPLACED for an old option alias 2016-08-31 14:46:21 +02:00
wm4 46f1ce1e2f input: remove redundant log message 2016-07-04 10:50:00 +02:00
wm4 447da032a3 input: do not force double-click emulation for artificial commands
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.
2016-03-26 20:03:11 +01:00
wm4 b4f63cbbec input: ignore --input-cursor for events injected by input commands
Apparently useful for window embedding.

Fixes #2750.
2016-02-04 23:01:15 +01:00
Dmitrij D. Czarkoff ea442fa047 mpv_talloc.h: rename from talloc.h
This change helps avoiding conflict with talloc.h from libtalloc.
2016-01-11 21:05:55 +01:00
wm4 f9ba1a3ddf demux: remove weird tripple-buffering for the sh_stream list
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.
2015-12-23 21:52:16 +01:00
wm4 b0381d27eb input: add a catch-all "unmapped" command
This can be used to grab all unmapped keys.

Fixes #2612.
2015-12-23 19:13:45 +01:00
wm4 3e1aed8f40 input: add key name to script-binding command response
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.
2015-12-23 19:10:48 +01:00
James Ross-Gowan 7558d1ed7b win32: input: use Vista CancelIoEx
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.
2015-12-20 21:06:02 +11:00
wm4 392ae68e5f options: fix --no-config
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.)
2015-09-05 15:33:19 +02:00
wm4 caebbded67 command: define-section with empty contents removes a section 2015-08-06 00:17:30 +02:00