2008-12-13 18:28:00 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2008-12-13 18:28:00 +00:00
|
|
|
*
|
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 (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.
2017-06-19 11:02:35 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
2008-12-13 18:28:00 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2008-12-13 18:28:00 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
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 (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.
2017-06-19 11:02:35 +00:00
|
|
|
* GNU Lesser General Public License for more details.
|
2008-12-13 18:28:00 +00:00
|
|
|
*
|
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 (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.
2017-06-19 11:02:35 +00:00
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2008-12-13 18:28:00 +00:00
|
|
|
*/
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#ifndef MPLAYER_INPUT_H
|
|
|
|
#define MPLAYER_INPUT_H
|
2008-01-01 21:35:58 +00:00
|
|
|
|
2012-03-21 00:23:35 +00:00
|
|
|
#include <stdbool.h>
|
2014-08-29 10:09:04 +00:00
|
|
|
#include "misc/bstr.h"
|
2012-03-21 00:23:35 +00:00
|
|
|
|
2013-12-26 16:10:35 +00:00
|
|
|
#include "cmd_list.h"
|
|
|
|
#include "cmd_parse.h"
|
2002-03-19 13:29:28 +00:00
|
|
|
|
2014-09-10 01:16:43 +00:00
|
|
|
// For mp_input_put_key(): release all keys that are down.
|
|
|
|
#define MP_INPUT_RELEASE_ALL -1
|
2011-05-01 12:57:39 +00:00
|
|
|
|
2013-12-15 22:35:36 +00:00
|
|
|
enum mp_cmd_flags {
|
2012-09-25 01:24:38 +00:00
|
|
|
MP_ON_OSD_NO = 0, // prefer not using OSD
|
|
|
|
MP_ON_OSD_AUTO = 1, // use default behavior of the specific command
|
|
|
|
MP_ON_OSD_BAR = 2, // force a bar, if applicable
|
|
|
|
MP_ON_OSD_MSG = 4, // force a message, if applicable
|
2013-12-15 22:35:36 +00:00
|
|
|
MP_EXPAND_PROPERTIES = 8, // expand strings as properties
|
2014-11-20 22:41:01 +00:00
|
|
|
MP_ALLOW_REPEAT = 16, // if used as keybinding, allow key repeat
|
2017-04-01 18:36:39 +00:00
|
|
|
MP_ASYNC_CMD = 32,
|
2013-12-15 22:35:36 +00:00
|
|
|
|
|
|
|
MP_ON_OSD_FLAGS = MP_ON_OSD_NO | MP_ON_OSD_AUTO |
|
|
|
|
MP_ON_OSD_BAR | MP_ON_OSD_MSG,
|
2012-09-09 00:08:08 +00:00
|
|
|
};
|
|
|
|
|
2012-08-24 11:29:28 +00:00
|
|
|
enum mp_input_section_flags {
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
// If a key binding is not defined in the current section, do not search the
|
|
|
|
// other sections for it (like the default section). Instead, an unbound
|
|
|
|
// key warning will be printed.
|
|
|
|
MP_INPUT_EXCLUSIVE = 1,
|
2014-02-19 14:40:04 +00:00
|
|
|
// Prefer it to other sections.
|
|
|
|
MP_INPUT_ON_TOP = 2,
|
2013-08-31 19:59:37 +00:00
|
|
|
// Let mp_input_test_dragging() return true, even if inside the mouse area.
|
2014-02-19 14:40:04 +00:00
|
|
|
MP_INPUT_ALLOW_VO_DRAGGING = 4,
|
input: don't deliver mouse events if mouse area is not set
This caused the OSC to be always visible at startup on X11:
- EnterNotify event send a mouse event to input.c
- OSC has not completely initialized yet, and no mouse area is set
- mouse event is dispatched to "showhide" OSC section
- OSC becomes visible, regardless of mouse position
Fix this by treating the mouse area as empty if it's not set, instead of
infinite as it was before this commit. This means an input section must
set a mouse area to receive mouse events at all. We also have to change
the default section to receive mouse events with the new behavior.
Also, if MOUSE_MOVE is unmapped (or mapped to something that doesn't
parse), and produces no command, the mouse position wouldn't be updated
(because the mouse position is bound to input commands), so we have to
generate a dummy command in this case.
(This matters only for the OSC, On Screen Controller, which isn't merged
yet, so these changes shouldn't have much effect right now.)
2013-09-05 21:58:51 +00:00
|
|
|
// Don't force mouse pointer visible, even if inside the mouse area.
|
2014-02-19 14:40:04 +00:00
|
|
|
MP_INPUT_ALLOW_HIDE_CURSOR = 8,
|
2012-08-24 11:29:28 +00:00
|
|
|
};
|
2002-01-30 12:46:03 +00:00
|
|
|
|
2008-04-30 04:15:52 +00:00
|
|
|
struct input_ctx;
|
2013-12-20 17:01:04 +00:00
|
|
|
struct mp_log;
|
2008-04-30 04:15:52 +00:00
|
|
|
|
2018-01-10 00:20:58 +00:00
|
|
|
// Arbitrary upper bound for sanity.
|
|
|
|
#define MP_CMD_MAX_ARGS 100
|
|
|
|
|
2011-07-16 15:17:48 +00:00
|
|
|
struct mp_cmd_arg {
|
2013-11-28 18:04:16 +00:00
|
|
|
const struct m_option *type;
|
2011-07-16 15:17:48 +00:00
|
|
|
union {
|
|
|
|
int i;
|
|
|
|
float f;
|
2013-02-24 20:16:23 +00:00
|
|
|
double d;
|
2011-07-16 15:17:48 +00:00
|
|
|
char *s;
|
2014-02-22 06:28:05 +00:00
|
|
|
char **str_list;
|
2013-07-08 17:27:45 +00:00
|
|
|
void *p;
|
2011-07-16 15:17:48 +00:00
|
|
|
} v;
|
|
|
|
};
|
2002-01-30 12:46:03 +00:00
|
|
|
|
|
|
|
typedef struct mp_cmd {
|
2011-07-16 14:47:02 +00:00
|
|
|
int id;
|
|
|
|
char *name;
|
2018-01-10 00:20:58 +00:00
|
|
|
struct mp_cmd_arg *args;
|
2012-03-21 00:23:35 +00:00
|
|
|
int nargs;
|
2013-12-15 22:35:36 +00:00
|
|
|
int flags; // mp_cmd_flags bitfield
|
2012-10-13 19:10:20 +00:00
|
|
|
bstr original;
|
2013-06-19 16:19:45 +00:00
|
|
|
char *input_section;
|
2014-11-23 14:08:49 +00:00
|
|
|
bool is_up_down : 1;
|
|
|
|
bool is_up : 1;
|
2014-11-24 15:48:34 +00:00
|
|
|
bool emit_on_up : 1;
|
2014-11-23 14:08:49 +00:00
|
|
|
bool is_mouse_button : 1;
|
|
|
|
bool repeated : 1;
|
|
|
|
bool mouse_move : 1;
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
int mouse_x, mouse_y;
|
2011-07-17 01:47:50 +00:00
|
|
|
struct mp_cmd *queue_next;
|
2013-11-05 23:05:12 +00:00
|
|
|
double scale; // for scaling numeric arguments
|
2017-04-25 08:03:06 +00:00
|
|
|
int scale_units;
|
2013-11-28 18:04:16 +00:00
|
|
|
const struct mp_cmd_def *def;
|
command: add a mechanism to allow scripts to intercept file loads
A vague idea to get something similar what libquvi did.
Undocumented because it might change a lot, or even be removed. To give
an idea what it does, a Lua script could do the following:
-- type ID priority
mp.commandv("hook_add", "on_load", 0, 0)
mp.register_script_message("hook_run", function(param, param2)
-- param is "0", the user-chosen ID from the hook_add command
-- param2 is the magic value that has to be passed to finish
-- the hook
mp.resume_all()
-- do something, maybe set options that are reset on end:
mp.set_property("file-local-options/name", "value")
-- or change the URL that's being opened:
local url = mp.get_property("stream-open-filename")
mp.set_property("stream-open-filename", url .. ".png")
-- let the player (or the next script) continue
mp.commandv("hook_ack", param2)
end)
2014-10-15 21:09:53 +00:00
|
|
|
char *sender; // name of the client API user which sent this
|
2015-12-23 18:10:38 +00:00
|
|
|
char *key_name; // string representation of the key binding
|
2002-01-30 12:46:03 +00:00
|
|
|
} mp_cmd_t;
|
|
|
|
|
input: redo how --input-file is handled
Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.
This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.
On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.
Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.
Tested on wine; might not work on a real Windows.
2014-08-24 21:50:43 +00:00
|
|
|
struct mp_input_src {
|
|
|
|
struct mpv_global *global;
|
|
|
|
struct mp_log *log;
|
|
|
|
struct input_ctx *input_ctx;
|
|
|
|
|
2014-09-09 20:11:45 +00:00
|
|
|
struct mp_input_src_internal *in;
|
input: redo how --input-file is handled
Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.
This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.
On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.
Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.
Tested on wine; might not work on a real Windows.
2014-08-24 21:50:43 +00:00
|
|
|
|
2014-09-14 14:21:04 +00:00
|
|
|
// If not-NULL: called before destroying the input_src. Should unblock the
|
|
|
|
// reader loop, and make it exit. (Use with mp_input_add_thread_src().)
|
|
|
|
void (*cancel)(struct mp_input_src *src);
|
|
|
|
// Called after the reader thread returns, and cancel() won't be called
|
|
|
|
// again. This should make sure that nothing after this call accesses src.
|
|
|
|
void (*uninit)(struct mp_input_src *src);
|
input: redo how --input-file is handled
Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.
This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.
On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.
Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.
Tested on wine; might not work on a real Windows.
2014-08-24 21:50:43 +00:00
|
|
|
|
|
|
|
// For free use by the implementer.
|
|
|
|
void *priv;
|
|
|
|
};
|
|
|
|
|
2014-09-09 21:44:38 +00:00
|
|
|
// Add an input source that runs on a thread. The source is automatically
|
|
|
|
// removed if the thread loop exits.
|
|
|
|
// ctx: this is passed to loop_fn.
|
|
|
|
// loop_fn: this is called once inside of a new thread, and should not return
|
2014-09-14 14:21:04 +00:00
|
|
|
// until all input is read, or src->cancel is called by another thread.
|
2014-09-09 21:44:38 +00:00
|
|
|
// You must call mp_input_src_init_done(src) early during init to signal
|
2014-09-14 14:21:04 +00:00
|
|
|
// success (then src->cancel may be called at a later point); on failure,
|
2014-09-09 21:44:38 +00:00
|
|
|
// return from loop_fn immediately.
|
|
|
|
// Returns >=0 on success, <0 on failure to allocate resources.
|
2014-09-14 14:21:04 +00:00
|
|
|
// Do not set src->cancel after mp_input_src_init_done() has been called.
|
2014-09-09 21:44:38 +00:00
|
|
|
int mp_input_add_thread_src(struct input_ctx *ictx, void *ctx,
|
|
|
|
void (*loop_fn)(struct mp_input_src *src, void *ctx));
|
|
|
|
|
|
|
|
// Signal successful init.
|
|
|
|
// Must be called on the same thread as loop_fn (see mp_input_add_thread_src()).
|
2014-09-14 14:21:04 +00:00
|
|
|
// Set src->cancel and src->uninit (if needed) before calling this.
|
2014-09-09 21:44:38 +00:00
|
|
|
void mp_input_src_init_done(struct mp_input_src *src);
|
|
|
|
|
input: redo how --input-file is handled
Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.
This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.
On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.
Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.
Tested on wine; might not work on a real Windows.
2014-08-24 21:50:43 +00:00
|
|
|
// Feed text data, which will be split into lines of commands.
|
|
|
|
void mp_input_src_feed_cmd_text(struct mp_input_src *src, char *buf, size_t len);
|
|
|
|
|
2013-07-02 12:00:24 +00:00
|
|
|
// Process keyboard input. code is a key code from keycodes.h, possibly
|
|
|
|
// with modifiers applied. MP_INPUT_RELEASE_ALL is also a valid value.
|
|
|
|
void mp_input_put_key(struct input_ctx *ictx, int code);
|
|
|
|
|
2016-02-04 22:01:15 +00:00
|
|
|
// Like mp_input_put_key(), but ignore mouse disable option for mouse buttons.
|
|
|
|
void mp_input_put_key_artificial(struct input_ctx *ictx, int code);
|
|
|
|
|
2013-07-02 12:00:24 +00:00
|
|
|
// Like mp_input_put_key(), but process all UTF-8 characters in the given
|
|
|
|
// string as key events.
|
|
|
|
void mp_input_put_key_utf8(struct input_ctx *ictx, int mods, struct bstr t);
|
2011-07-17 01:47:50 +00:00
|
|
|
|
2013-07-25 16:08:57 +00:00
|
|
|
// Process scrolling input. Support for precise scrolling. Scales the given
|
|
|
|
// scroll amount add multiplies it with the command (seeking, sub-delay, etc)
|
2017-09-02 14:00:52 +00:00
|
|
|
void mp_input_put_wheel(struct input_ctx *ictx, int direction, double value);
|
2013-07-25 16:08:57 +00:00
|
|
|
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
// Update mouse position (in window coordinates).
|
|
|
|
void mp_input_set_mouse_pos(struct input_ctx *ictx, int x, int y);
|
|
|
|
|
2016-02-04 22:01:15 +00:00
|
|
|
// Like mp_input_set_mouse_pos(), but ignore mouse disable option.
|
|
|
|
void mp_input_set_mouse_pos_artificial(struct input_ctx *ictx, int x, int y);
|
|
|
|
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
void mp_input_get_mouse_pos(struct input_ctx *ictx, int *x, int *y);
|
|
|
|
|
2014-07-27 19:53:29 +00:00
|
|
|
// Return whether we want/accept mouse input.
|
|
|
|
bool mp_input_mouse_enabled(struct input_ctx *ictx);
|
|
|
|
|
2014-10-09 16:28:37 +00:00
|
|
|
bool mp_input_vo_keyboard_enabled(struct input_ctx *ictx);
|
client API, X11: change default keyboard input handling again
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.
2014-09-28 18:11:00 +00:00
|
|
|
|
2014-07-27 19:33:11 +00:00
|
|
|
/* Make mp_input_set_mouse_pos() mangle the mouse coordinates. Hack for certain
|
|
|
|
* VOs. dst=NULL, src=NULL reset it. src can be NULL.
|
|
|
|
*/
|
|
|
|
struct mp_rect;
|
|
|
|
void mp_input_set_mouse_transform(struct input_ctx *ictx, struct mp_rect *dst,
|
|
|
|
struct mp_rect *src);
|
|
|
|
|
2011-07-16 14:47:02 +00:00
|
|
|
// Add a command to the command queue.
|
|
|
|
int mp_input_queue_cmd(struct input_ctx *ictx, struct mp_cmd *cmd);
|
2002-02-23 21:13:35 +00:00
|
|
|
|
2014-09-07 18:44:54 +00:00
|
|
|
// Return next queued command, or NULL.
|
|
|
|
struct mp_cmd *mp_input_read_cmd(struct input_ctx *ictx);
|
2002-01-30 12:46:03 +00:00
|
|
|
|
2012-10-13 19:09:42 +00:00
|
|
|
// Parse text and return corresponding struct mp_cmd.
|
|
|
|
// The location parameter is for error messages.
|
2013-09-27 13:30:59 +00:00
|
|
|
struct mp_cmd *mp_input_parse_cmd(struct input_ctx *ictx, bstr str,
|
|
|
|
const char *location);
|
2002-11-14 23:41:44 +00:00
|
|
|
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
// Set current input section. The section is appended on top of the list of
|
|
|
|
// active sections, so its bindings are considered first. If the section was
|
|
|
|
// already active, it's moved to the top as well.
|
|
|
|
// name==NULL will behave as if name=="default"
|
2012-08-24 11:29:28 +00:00
|
|
|
// flags is a bitfield of enum mp_input_section_flags values
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
void mp_input_enable_section(struct input_ctx *ictx, char *name, int flags);
|
|
|
|
|
|
|
|
// Undo mp_input_enable_section().
|
|
|
|
// name==NULL will behave as if name=="default"
|
|
|
|
void mp_input_disable_section(struct input_ctx *ictx, char *name);
|
|
|
|
|
|
|
|
// Like mp_input_set_section(ictx, ..., 0) for all sections.
|
|
|
|
void mp_input_disable_all_sections(struct input_ctx *ictx);
|
|
|
|
|
|
|
|
// Set the contents of an input section.
|
|
|
|
// name: name of the section, for mp_input_set_section() etc.
|
|
|
|
// location: location string (like filename) for error reporting
|
|
|
|
// contents: list of keybindings, like input.conf
|
|
|
|
// a value of NULL deletes the section
|
|
|
|
// builtin: create as builtin section; this means if the user defines bindings
|
|
|
|
// using "{name}", they won't be ignored or overwritten - instead,
|
|
|
|
// they are preferred to the bindings defined with this call
|
2016-09-20 13:31:25 +00:00
|
|
|
// owner: string ID of the client which defined this, or NULL
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
// If the section already exists, its bindings are removed and replaced.
|
|
|
|
void mp_input_define_section(struct input_ctx *ictx, char *name, char *location,
|
2016-09-20 13:31:25 +00:00
|
|
|
char *contents, bool builtin, char *owner);
|
|
|
|
|
|
|
|
// Remove all sections that have been defined by the given owner.
|
|
|
|
void mp_input_remove_sections_by_owner(struct input_ctx *ictx, char *owner);
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
|
|
|
|
// Define where on the screen the named input section should receive.
|
|
|
|
// Setting a rectangle of size 0 unsets the mouse area.
|
|
|
|
// A rectangle with negative size disables mouse input for this section.
|
|
|
|
void mp_input_set_section_mouse_area(struct input_ctx *ictx, char *name,
|
|
|
|
int x0, int y0, int x1, int y1);
|
2007-06-07 18:06:53 +00:00
|
|
|
|
2013-05-16 21:17:46 +00:00
|
|
|
// Used to detect mouse movement.
|
2013-05-25 16:31:06 +00:00
|
|
|
unsigned int mp_input_get_mouse_event_counter(struct input_ctx *ictx);
|
2013-05-16 21:17:46 +00:00
|
|
|
|
input: handle mouse movement differently
Before this commit, mouse movement events emitted a special command
("set_mouse_pos"), which was specially handled in command.c. This was
once special-cased to the dvdnav and menu code, and did nothing after
libmenu and dvdnav were removed.
Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"),
which then can be bound to an arbitrary command. The mouse position is
now managed in input.c. A command which actually needs the mouse
position can use either mp_input_get_mouse_pos() or mp_get_osd_mouse_pos()
to query it. The former returns raw window-space coordinates, while the
latter returns coordinates transformed to OSD- space. (Both are the same
for most VOs, except vo_xv and vo_x11, which can't render OSD in
window-space. These require extra code for mapping mouse position.)
As of this commit, there is still nothing that uses mouse movement, so
MOUSE_MOVE is mapped to "ignore" to silence warnings when moving the
mouse (much like MOUSE_BTN0).
Extend the concept of input sections. Allow multiple sections to be
active at once, and organize them as stack. Bindings from the top of
the stack are preferred to lower ones.
Each section has a mouse input section associated, inside which mouse
events are associated with the bindings. If the mouse pointer is
outside of a section's mouse area, mouse events will be dispatched to
an input section lower on the stack of active sections. This is intended
for scripting, which is to be added later. Two scripts could occupy
different areas of the screen without conflicting with each other. (If
it turns out that this mechanism is useless, we'll just remove it
again.)
2013-04-26 00:13:30 +00:00
|
|
|
// Test whether there is any input section which wants to receive events.
|
|
|
|
// Note that the mouse event is always delivered, even if this returns false.
|
|
|
|
bool mp_input_test_mouse_active(struct input_ctx *ictx, int x, int y);
|
|
|
|
|
|
|
|
// Whether input.c wants mouse drag events at this mouse position. If this
|
|
|
|
// returns false, some VOs will initiate window dragging.
|
|
|
|
bool mp_input_test_dragging(struct input_ctx *ictx, int x, int y);
|
|
|
|
|
2011-07-16 14:47:02 +00:00
|
|
|
// Initialize the input system
|
2013-09-10 06:29:45 +00:00
|
|
|
struct mpv_global;
|
2016-09-16 12:25:50 +00:00
|
|
|
struct input_ctx *mp_input_init(struct mpv_global *global,
|
|
|
|
void (*wakeup_cb)(void *ctx),
|
|
|
|
void *wakeup_ctx);
|
2002-01-30 12:46:03 +00:00
|
|
|
|
2016-09-21 13:56:54 +00:00
|
|
|
void mp_input_load_config(struct input_ctx *ictx);
|
|
|
|
|
|
|
|
void mp_input_update_opts(struct input_ctx *ictx);
|
2014-09-27 13:47:49 +00:00
|
|
|
|
2013-07-27 19:26:00 +00:00
|
|
|
void mp_input_uninit(struct input_ctx *ictx);
|
2008-08-12 11:22:26 +00:00
|
|
|
|
2016-09-16 12:25:50 +00:00
|
|
|
// Return number of seconds until the next autorepeat event will be generated.
|
|
|
|
// Returns INFINITY if no autorepeated key is active.
|
|
|
|
double mp_input_get_delay(struct input_ctx *ictx);
|
2014-09-07 18:44:54 +00:00
|
|
|
|
2012-03-25 19:58:48 +00:00
|
|
|
// Wake up sleeping input loop from another thread.
|
|
|
|
void mp_input_wakeup(struct input_ctx *ictx);
|
|
|
|
|
stream: redo playback abort handling
This mechanism originates from MPlayer's way of dealing with blocking
network, but it's still useful. On opening and closing, mpv waits for
network synchronously, and also some obscure commands and use-cases can
lead to such blocking. In these situations, the stream is asynchronously
forced to stop by "interrupting" it.
The old design interrupting I/O was a bit broken: polling with a
callback, instead of actively interrupting it. Change the direction of
this. There is no callback anymore, and the player calls
mp_cancel_trigger() to force the stream to return.
libavformat (via stream_lavf.c) has the old broken design, and fixing it
would require fixing libavformat, which won't happen so quickly. So we
have to keep that part. But everything above the stream layer is
prepared for a better design, and more sophisticated methods than
mp_cancel_test() could be easily introduced.
There's still one problem: commands are still run in the central
playback loop, which we assume can block on I/O in the worst case.
That's not a problem yet, because we simply mark some commands as being
able to stop playback of the current file ("quit" etc.), so input.c
could abort playback as soon as such a command is queued. But there are
also commands abort playback only conditionally, and the logic for that
is in the playback core and thus "unreachable". For example,
"playlist_next" aborts playback only if there's a next file. We don't
want it to always abort playback.
As a quite ugly hack, abort playback only if at least 2 abort commands
are queued - this pretty much happens only if the core is frozen and
doesn't react to input.
2014-09-13 12:23:08 +00:00
|
|
|
// Used to asynchronously abort playback. Needed because the core still can
|
|
|
|
// block on network in some situations.
|
2017-01-18 16:13:26 +00:00
|
|
|
void mp_input_set_cancel(struct input_ctx *ictx, void (*cb)(void *c), void *c);
|
2002-10-23 14:46:20 +00:00
|
|
|
|
2013-12-01 05:23:39 +00:00
|
|
|
// If this returns true, use Right Alt key as Alt Gr to produce special
|
|
|
|
// characters. If false, count Right Alt as the modifier Alt key.
|
|
|
|
bool mp_input_use_alt_gr(struct input_ctx *ictx);
|
|
|
|
|
2017-07-25 13:51:40 +00:00
|
|
|
// Return true if mpv should intercept keyboard media keys
|
|
|
|
bool mp_input_use_media_keys(struct input_ctx *ictx);
|
|
|
|
|
2014-01-04 18:42:01 +00:00
|
|
|
// Like mp_input_parse_cmd_strv, but also run the command.
|
2014-10-10 20:58:28 +00:00
|
|
|
void mp_input_run_cmd(struct input_ctx *ictx, const char **cmd);
|
2014-01-04 15:59:22 +00:00
|
|
|
|
2014-10-19 14:44:33 +00:00
|
|
|
void mp_input_set_repeat_info(struct input_ctx *ictx, int rate, int delay);
|
|
|
|
|
2014-09-14 14:21:04 +00:00
|
|
|
void mp_input_pipe_add(struct input_ctx *ictx, const char *filename);
|
input: redo how --input-file is handled
Abandon the "old" infrastructure for --input-file (mp_input_add_fd(),
select() loop, non-blocking reads). Replace it with something that
starts a reader thread, using blocking input.
This is for the sake of Windows. Windows is a truly insane operating
system, and there's not even a way to read a pipe in a non-blocking
way, or to wait for new input in an interruptible way (like with
poll()). And unfortunately, some want to use pipe to send input to
mpv. There are probably (slightly) better IPC mechanisms available
on Windows, but for the sake of platform uniformity, make this work
again for now.
On Vista+, CancelIoEx() could probably be used. But there's no way on
XP. Also, that function doesn't work on wine, making development
harder. We could forcibly terminate the thread, which might work, but
is unsafe. So what we do is starting a thread, and if we don't want
the pipe input anymore, we just abandon the thread. The thread might
remain blocked forever, but if we exit the process, the kernel will
forcibly kill it. On Unix, just use poll() to handle this.
Unfortunately the code is pretty crappy, but it's ok, because it's late
and I wanted to stop working on this an hour ago.
Tested on wine; might not work on a real Windows.
2014-08-24 21:50:43 +00:00
|
|
|
|
2014-10-19 14:44:33 +00:00
|
|
|
struct mp_ipc_ctx;
|
|
|
|
struct mp_client_api;
|
2017-06-27 11:47:46 +00:00
|
|
|
|
|
|
|
// Platform specific implementation, provided by ipc-*.c.
|
2014-10-19 14:44:33 +00:00
|
|
|
struct mp_ipc_ctx *mp_init_ipc(struct mp_client_api *client_api,
|
|
|
|
struct mpv_global *global);
|
|
|
|
void mp_uninit_ipc(struct mp_ipc_ctx *ctx);
|
2014-09-19 15:36:37 +00:00
|
|
|
|
2016-03-17 08:27:30 +00:00
|
|
|
// Serialize the given mpv_event structure to JSON. Returns an allocated string.
|
|
|
|
struct mpv_event;
|
|
|
|
char *mp_json_encode_event(struct mpv_event *event);
|
|
|
|
|
|
|
|
// Given the raw IPC input buffer "buf", remove the first newline-separated
|
|
|
|
// command, execute it and return the result (if any) as an allocated string.
|
|
|
|
struct mpv_handle;
|
|
|
|
char *mp_ipc_consume_next_command(struct mpv_handle *client, void *ctx, bstr *buf);
|
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#endif /* MPLAYER_INPUT_H */
|