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
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2008-12-13 18:28:00 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
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
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2015-04-13 07:36:54 +00:00
|
|
|
* 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
|
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
|
|
|
|
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;
|
2011-07-16 15:17:48 +00:00
|
|
|
struct mp_cmd_arg args[MP_CMD_MAX_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
|
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
|
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);
|
|
|
|
|
|
|
|
// 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)
|
|
|
|
void mp_input_put_axis(struct input_ctx *ictx, int direction, double value);
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
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
|
|
|
|
// If the section already exists, its bindings are removed and replaced.
|
|
|
|
void mp_input_define_section(struct input_ctx *ictx, char *name, char *location,
|
|
|
|
char *contents, bool builtin);
|
|
|
|
|
|
|
|
// 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;
|
|
|
|
struct input_ctx *mp_input_init(struct mpv_global *global);
|
2002-01-30 12:46:03 +00:00
|
|
|
|
2014-09-27 13:47:49 +00:00
|
|
|
// Load config, options, and devices.
|
|
|
|
void mp_input_load(struct input_ctx *ictx);
|
|
|
|
|
2013-07-27 19:26:00 +00:00
|
|
|
void mp_input_uninit(struct input_ctx *ictx);
|
2008-08-12 11:22:26 +00:00
|
|
|
|
2014-09-07 18:44:54 +00:00
|
|
|
// Sleep for the given amount of seconds, until mp_input_wakeup() is called,
|
|
|
|
// or new input arrives. seconds<=0 returns immediately.
|
|
|
|
void mp_input_wait(struct input_ctx *ictx, double seconds);
|
|
|
|
|
2012-03-25 19:58:48 +00:00
|
|
|
// Wake up sleeping input loop from another thread.
|
|
|
|
void mp_input_wakeup(struct input_ctx *ictx);
|
|
|
|
|
2014-04-15 20:50:16 +00:00
|
|
|
void mp_input_wakeup_nolock(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.
|
|
|
|
struct mp_cancel;
|
|
|
|
void mp_input_set_cancel(struct input_ctx *ictx, struct mp_cancel *cancel);
|
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);
|
|
|
|
|
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;
|
|
|
|
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
|
|
|
|
2008-02-22 09:09:46 +00:00
|
|
|
#endif /* MPLAYER_INPUT_H */
|