Commit Graph

841 Commits

Author SHA1 Message Date
Thomas Weißschuh 5d3680c314 input: add function keys F13-F24 2022-09-02 14:05:46 +02:00
Avi Halachmi (:avih) 2a183c5ca7 input: new option: --no-input-builtin-bindings
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)
2021-10-11 22:16:51 +03:00
Avi Halachmi (:avih) 3abb23d70f command: don't hardcode commands list to be repeatable
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
2021-08-17 22:45:39 +03:00
Avi Halachmi (:avih) 9f6cbf3a4d input: arguments quoting: support single-quotes
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.
2021-07-30 09:52:34 +03:00
Avi Halachmi (:avih) 73c9509720 input: argument custom quotes: use ` instead of !
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).
2021-07-30 09:52:34 +03:00
Avi Halachmi (:avih) 4f129a3eca input.conf syntax: support custom quotes !XstringX!
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).
2020-12-31 12:54:33 +02:00
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 810b37fc3f ipc: mark client sockets as CLOEXEC
I suppose it would have left the socket open if the client closed its
FD.
2020-05-15 16:37:41 +02:00
wm4 a58b2df3f8 command: add input-key-list property
Fixes: #7698
2020-05-14 22:22:33 +02:00
wm4 0049ea38be ipc: exit client if the FD is invalid
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).
2020-05-14 21:42:46 +02:00
wm4 26bd8479d0 ipc: make --input-ipc-client terminate player on connection close
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
2020-05-14 21:40:43 +02:00
wm4 1bdc3bed00 ipc: add --input-ipc-client option
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
2020-04-09 01:05:51 +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 88194d05d3 ipc: fix recently added memory leak
Sucks.
2020-03-27 00:07:03 +01:00
wm4 218d6643e9 client API, lua, ipc: unify event struct return
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.
2020-03-21 19:33:48 +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 c418aa3807 ipc: allow sending commands with named arguments
This has been part of the libmpv for a while, so the implementation in
the IPC code is quite simple: just pass the mpv_node representing the
value of the "command" field without further checks to
mpv_command_node().

The only problem are the IPC-specific commands, which essentially have
their own dispatch mechanism. They expect an array. I'm not going to
rewrite the dispatch mechanism, so these still work only with an array.
I decided make the other case explicit with cmd==NULL. (I could also
have set cmd=="", which would have avoided changing each if condition
since "" matches no existing command, but that felt dirty.)
2020-02-24 00:31:46 +01:00
wm4 b05550fe55 ipc: implement asynchronous commands
I decided to make this explicit. The alternative would have been making
all commands asynchronous always, like a small note in the manpage
threatened. I think that could have caused compatibility issues.

As a design decision, this does not send a reply if an async command
started. This could be a good or bad idea, but in any case, it will make
async command look almost like synchronous ones, except they don't block
the IPC protocol.
2020-02-24 00:14:54 +01:00
wm4 e2ab6b7f35 scripting: add a way to run sub processes as "scripts"
This is just a more convenient way to start IPC client scripts per mpv
instance.

Does not work on Windows, although it could if the subprocess and IPC
parts are implemented (and I guess .exe/.bat suffixes are required).
Also untested whether it builds on Windows. A lot of other things are
untested too, so don't complain.
2020-02-19 22:18:15 +01:00
wm4 e22b771ff8 build: remove fchmod() check
This is UNIX-only code, and this function has been in POSIX since
forever. Even Android has it. The test should be unnecessary, so remove
it.
2020-02-19 20:38:12 +01:00
wm4 2567997ecf input: log commands with parameter names 2020-02-19 16:25:18 +01:00
der richter 77d42d5532 input: add new PLAYONLY and PAUSEONLY MP_KEY key codes
since the old PLAY and PAUSE key codes cycle through the pause property,
the new key codes only explicitly set the pause property.
2020-01-26 12:09:55 +01:00
wm4 da913998d3 input: fix cycle 2nd argument stringification
Triggered the fallback code that formatted the argument as "(NULL)".
2020-01-19 20:53:26 +01:00
wm4 4b168bcda3 input: escape command parameters when logging
Some complex commands (like commands generated by scripts to define key
bindings or the OSD overlay command) contain new lines, which "corrupts"
logging.

Fix this by escaping the parameters C-style. Abuse the JSON writer for
this, which already has code to vaguely produce C-style escapes.

At first I considered stripping the quotes, but then I thought it's
actually a good idea to leave them in, as it makes things clearer.

Follows an idea by avih.
2020-01-12 01:04:33 +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
wm4 3ed96cca88 command: reduce OSC/stats log spam
For some inexplicable reason, the OSC runs the expand-text command a
_lot_. This command is logged at the log file default log level, so the
log file can quickly fill up with these messages. It directly violates
the mpv logging policy: per-frame (or similarly common) log messages
should not be enabled by default for the log file.

stats.lua uses the show-text command for some reason (instead of
creating its own OSD layer).

Explicitly reduce the log level for expand-text and some other commands.
Also reduce the log level for commands triggered by mouse movement.

The previous commit also contributed some to reduce log spam.

Fixes: #4771
2019-12-19 12:52:13 +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 1cb085a82e options: get rid of GLOBAL_CONFIG hack
Just an implementation detail that can be cleaned up now. Internally,
m_config maintains a tree of m_sub_options structs, except for the root
it was not defined explicitly. GLOBAL_CONFIG was a hack to get access to
it anyway. Define it explicitly instead.
2019-11-29 12:14:43 +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 033af5390f input: make MP_INPUT_RELEASE_ALL a pseudo-key
Should be without consequences. I think this is less trouble, because
code frequently wants to add/remove bits for modifiers and key state
from key codes, and with this change you can't accidentally break it by
testing or removing bits from the old -1 value.
2019-11-22 01:19:00 +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 c184e290b0 sdl: prevent concurrent use of SDL in different threads
sdl_gamepad.c and vo_sdl.c both have their own event loops and run in
separate threads. They don't know of each other (and shouldn't). Since
SDL only has one global event loop (why didn't they fix this in SDL2?),
these obviously clash. The actual behavior is relatively subtle, which
event being randomly dispatched to either of the threads.

This is very regrettable. Very.

Work this around. "Fortunately" SDL exposes its global state to some
degree. SDL_WasInit() returns whether a "subsystem" was initialized, and
you could say the one who initialized it owns it. Both SDL_INIT_VIDEO
and SDL_INIT_GAMECONTROLLER implicitly enable SDL_INIT_EVENTS, and the
event loop is indeed the resource that cannot be shared.

Unfortunately, this is still racy, since SDL_InitSubSystem is a second
call, and succeeds if the subsystem is already initialized (increases a
refcount I think). But good enough. Blame SDL for everything.

(I think I made this commit message too long. Nobody cares even.)

Fixes: #7085
2019-10-25 22:17:54 +02: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
wm4 8b0ff53b69 sdl_gamepad: fix typo in function name
As pointed out by LaserEyess on IRC.
2019-10-25 15:33:23 +02:00
wm4 49cde32be0 sdl_gamepad: fix function signature
This is semantically different in C.
2019-10-25 15:26:34 +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
thewisenerd 2a29950020 input: ignore empty lines on drag-drop mime data
do not outright err and quit the player for this
2019-09-21 15:39:47 +02:00
Anton Kindestam 8b83c89966 Merge commit '559a400ac36e75a8d73ba263fd7fa6736df1c2da' into wm4-commits--merge-edition
This bumps libmpv version to 1.103
2018-12-05 19:19:24 +01:00
Niklas Haas 880c59d189 ipc-unix: don't blow up on readonly fd://
On my system, when trying to use mpv with a read-only fd created by
python 3.7, `send` triggers ENOTSOCK, not EBADF. Extend the logic to
detect non-writable fds by this `errno`.
2018-10-31 09:20:44 +01:00
Ben Boeckel e3e1bdfb13 ipc-unix: leave room for a NUL terminator
The `strncpy` function will not always place a terminating `NUL` if the
source is longer than the destination buffer. Instead, let `strncpy`
truncate as it normally would, but leave the last byte alone (it is
zero-initialized when declared).
2018-10-31 09:20:26 +01:00