Making key up events implicit was sort-of a nice idea, but it's too
tricky and unreliable and makes the key lookup code (interpret_keys())
hard to reason about. See e.g. previous commit for subtle bugs and
issues this caused.
Make key-up events explicit instead. Add key up events to all VOs.
Any time MP_KEY_STATE_DOWN is used, the matching key up event must
use MP_KEY_STATE_UP.
Rewrite the key lookup code. It should be simpler and more robust now.
(Even though the LOC increases, because the new code is less "compact".)
Also, implement mouse leave events for X11. But evne on other
platforms, these events will be generated if mouse crosses a section's
mouse area boundaries within the mpv window.
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.)
This commit addresses some issues with the users had with the previous
implementation in commit c39efb9. Here's the changes:
* Use Quartz Event Taps to remove Media Key events mpv handles from
the global OS X queue. This prevents conflicts with iTunes. I did this on
the main thread since it is mostly idling. It's the playloop thread that
actually does all the work so there is no danger of blocking the event tap
callback.
* Introduce `--no-media-keys` switch so that users can disable all of mpv's
media key handling at runtime (some prefer iTunes for example).
* Use mpv's bindings so that users can customize what the media keys do via
input.conf. Current bindings are:
MK_PLAY cycle pause
MK_PREV playlist_prev
MK_NEXT playlist_next
An additional benefit of this implementation is that it is completly handled
by the `macosx_events` file instead of `macosx_application` making the
project organization more straightforward.
After killing the non functional AR support in c8fd9e5 I got much complaints so
this adds AR support back in (and it works). I am using the HIDRemote class by
Felix Schwarz and that part of the code is under the BSD license. I slightly
modified it replacing [NSApplication sharedApplication] with NSApp. The code
of the class is quite complex (probably because it had to deal with all the
edge cases with IOKit) but it works nicely as a black box.
In a later commit I'll remove the deprecation warnings caused by HIDRemote's
usage of Gestalt.
Check out `etc/input.conf` for the default bindings.
Apple Remote functionality is automatically compiled in when cocoa is enabled.
It can be disabled at runtime with the `--no-ar` option.
VOs can use the MP_KEY_STATE_DOWN modifier to pass key up/down events to
input.c, instead of just simple key presses. This allows doing key auto-
repeat handling in input.c, if the VO doesn't want to do that.
One issue is that so far, this code has been used only for mouse events,
even though the code was originally written with keyboard keys in mind.
One difference between mouse keys and keyboard keys is that the initial
key down should not generate an input command with mouse buttons
(input.c did that), while keyboard events should (input.c didn't do
that). Likewise, releasing a key should generate input commands for
mouse buttons releases, but not for the keyboard.
Change the code so mouse buttons (recognized via the MP_NO_REPEAT_KEY
flag) follow the old hehavior, while other keys generate input commands
on key down, but not on key release.
Note that a key release event is posted either using
MP_INPUT_RELEASE_ALL, or a normal key press event after having sent a an
event with MP_KEY_STATE_DOWN. This is probably a bit confusing, and a
MP_KEY_STATE_RELEASE should be added.
Fix shift-handling with MP_KEY_STATE_DOWN as well.
Do this to reduce conflicts with <linux/input.h>, which contains some
conflicting defines.
This changes the meaning of MP_KEY_DOWN:
KEY_DOWN is renamed to MP_KEY_DOWN (cursor down key)
MP_KEY_DOWN is renamed to MP_KEY_STATE_DOWN (modifier for key down state)
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.
Renames the following directories:
libaf -> audio/filter
libao2 -> audio/out
libvo -> video/out
libmpdemux -> demux
Split libmpcodecs:
vf* -> video/filter
vd*, dec_video.* -> video/decode
mp_image*, img_format*, ... -> video/
ad*, dec_audio.* -> audio/decode
libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.
Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.
sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).
Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
