Commit Graph

16 Commits

Author SHA1 Message Date
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
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 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 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 12d1404b04 player: make various commands for managing external tracks abortable
Until now, they could be aborted only by ending playback, and calling
mpv_abort_async_command didn't do anything.

This requires furthering the mess how playback abort is done. The main
reason why mp_cancel exists at all is to avoid that a "frozen" demuxer
(blocked on network I/O or whatever) cannot freeze the core. The core
should always get its way. Previously, there was a single mp_cancel
handle, that could be signaled, and all demuxers would unfreeze. With
external files, we might want to abort loading of a certain external
file, which automatically means they need a separate mp_cancel. So give
every demuxer its own mp_cancel, and "slave" it to whatever parent
mp_cancel handles aborting.

Since the mpv demuxer API conflates creating the demuxer and reading the
file headers, mp_cancel strictly need to be created before the demuxer
is created (or we couldn't abort loading). Although we give every
demuxer its own mp_cancel (as "enforced" by cancel_and_free_demuxer),
it's still rather messy to create/destroy it along with the demuxer.
2018-05-24 19:56:35 +02:00
wm4 12bd4fe9ab cmd: do not use a random value for MP_CMD_OPT_ARG
This flag is used only by the command parser. Its value overlapped with
some of the existing m_option flags, but only flags that did not matter
for the command parser (i.e. the flag bits used had mostly private uses
in each component). It's still a bit unclean and dangerous to use an
essentially random value, so reuse M_OPT_OPTIONAL_PARAM for it.

Since M_OPT_OPTIONAL_PARAM has a slightly longer name than
MP_CMD_OPT_ARG, I'm going to keep the old name.
2018-05-24 19:56:34 +02:00
wm4 e4fb23ed7d command: add a way to abort asynchronous commands
Many asynchronous commands are potentially long running operations, such
as loading something from network or running a foreign process.
Obviously it shouldn't just be possible for them to freeze the player if
they don't terminate as expected. Also, there will be situations where
you want to explicitly stop some of those operations explicitly. So add
an infrastructure for this.

Commands have to support this explicitly. The next commit uses this to
actually add support to a command.
2018-05-24 19:56:34 +02:00
wm4 d9bc97bda6 command: add a subprocess command
This supports named arguments. It benefits from the infrastructure of
async commands.

The plan is to reimplement Lua's utils.subprocess() on top of it.
2018-05-24 19:56:34 +02:00
wm4 95c4f0f769 input: remove unused field
This was forgotten in commit fb9bbf2a0d.
2018-05-24 19:56:34 +02:00
wm4 b440f6dfb3 command: add infrastructure for async commands
This enables two types of command behavior:

1. Plain async behavior, like "loadfile" not completing until the file
   is fully loaded.
2. Running parts of the command on worker threads, e.g. for I/O, such as
   "sub-add" doing network accesses on a thread while the core
   continues.

Both have no implementation yet, and most new code is actually inactive.
The plan is to implement a number of useful cases in the following
commits.

The most tricky part is handling internal keybindings (input.conf) and
the multi-command feature (concatenating commands with ";"). It requires
a bunch of roundabout code to make it do the expected thing in
combination with async commands.

There is the question how commands should be handled that come in at a
higher rate than what can be handled by the core. Currently, it will
simply queue up input.conf commands as long as memory lasts. The client
API is limited by the size of the reply queue per client. For commands
which require a worker thread, the thread pool is limited to 30 threads,
and then will queue up work in memory. The number is completely
arbitrary.
2018-05-24 19:56:34 +02:00
wm4 383da1bfd5 input: move an enum back to its correct place
This was accidentally moved together with the cmd stuff.
2018-05-24 19:56:33 +02:00
wm4 88498bcc92 input: rename weirdly named function 2018-05-03 01:20:01 +03:00
wm4 407f5b407a input: move some more cmd definitions to cmd.h
Now both command "descriptions" and runtime command instances are in
cmd.h, which makes sense to me. input.h is now for the actual input
context.
2018-05-03 01:20:01 +03:00
wm4 9fa0e6bf6a input: merge cmd_list.c with cmd.c
It doesn't really make sense to keep a separate cmd_list.c file, which
does _not_ contain a command list, but only a few minor helper
functions.
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