The terminal OSD code includes the handling of the terminal status line,
showing player OSD messages on the terminal, and showing subtitles on
terminal (the latter two only if there is no video window, or if
terminal OSD is forced).
This didn't handle some corner cases correctly. For example, showing an
OSD message on the terminal always cleared the previous line, even if
the line was an important message (or even just the command prompt, if
most other messages were silenced).
Attempt to handle this correctly by keeping track of how many lines the
terminal OSD currently consists of. Since there could be race conditions
with other messages being printed, implement this in msg.c. Now msg.c
expects that MSGL_STATUS messages rewrite the status line, so the caller
is forced to use a single mp_msg() call to set the status line.
Instead of littering print_status() all over the place, update the
status only once per playloop iteration in update_osd_msg(). In audio-
only mode, the status line might now be a little bit off, but it's
perhaps ok.
Print the status line only if it has changed, or if another message was
printed. This might help with extremely slow terminals, although in
audio+video mode, it'll still be updated very often (A-V sync display
changes on every frame).
Instead of hardcoding the terminal sequences, use
terminfo/termcap to get the sequences. Remove the --term-osd-esc option,
which allowed to override the hardcoded escapes - it's useless now.
The fallback for terminals with no escape sequences for moving the
cursor and clearing a line is removed. This somewhat breaks status line
display on these terminals, including the MS Windows console: instead of
querying the terminal size and clearing the line manually by padding the
output with spaces, the line is simply not cleared. I don't expect this
to be a problem on UNIX, and on MS Windows we could emulate escape
sequences. Note that terminal OSD (other than the status line) was
broken anyway on these terminals.
In osd.c, the function get_term_width() is not used anymore, so remove
it. To remind us that the MS Windows console apparently adds a line
break when writint the last column, adjust screen_width in terminal-
win.c accordingly.
This is necessary to start mpv without forcing a console window,
but also breaks console usability. A workaround is to call mpv
from a wrapper process that uses the console subsystem and helps
redirecting the standard streams and WriteConsole output to where
they belong.
There's a single mp_msg() in path.c, but all path lookup functions seem
to depend on it, so we get a rat-tail of stuff we have to change. This
is probably a good thing though, because we can have the path lookup
functions also access options, so we could allow overriding the default
config path, or ignore the MPV_HOME environment variable, and such
things.
Also take the chance to consistently add talloc_ctx parameters to the
path lookup functions.
Also, this change causes a big mess on configfiles.c. It's the same
issue: everything suddenly needs a (different) context argument. Make it
less wild by providing a mp_load_auto_profiles() function, which
isolates most of it to configfiles.c.
Until now, there were two functions to add input sources (stuff like
stdin input, slave mode, lirc, joystick). Unify them to a single
function (mp_input_add_fd()), and make sure the associated callbacks
always have a context parameter.
Change the lirc and joystick code such that they take store their state
in a context struct (probably worthless), and use the new mp_msg
replacements (the point of this refactoring).
Additionally, get rid of the ugly USE_FD0_CMD_SELECT etc. ifdeffery in
the terminal handling code.
Instead of making msg.c an ifdef hell for unix vs. windows code, move
the code to separate functions defined in terminal-unix.c/terminal-
win.c.
Drop the code that selects random colors for --msgmodule prefixes.
This comes with a real change in behavior: now the signal handler is set
only when the terminal input code is active (e.g. not with
--no-consolecontrols), but this should be ok.
In my opinion, config.h inclusions should be kept to a minimum. MPlayer
code really liked including config.h everywhere, though, even in often
used header files. Try to reduce this.
Since m_option.h and options.h are extremely often included, a lot of
files have to be changed.
Moving path.c/h to options/ is a bit questionable, but since this is
mainly about access to config files (which are also handled in
options/), it's probably ok.
The tmsg stuff was for the internal gettext() based translation system,
which nobody ever attempted to use and thus was removed. mp_gtext() and
set_osd_tmsg() were also for this.
mp_dbg was once enabled in debug mode only, but since we have log level
for enabling debug messages, it seems utterly useless.
Bug introduced by commit 6fb020f5. It doesn't always happen, since it is
caused by the playloop and cocoa UI code running in separate threads.
Fixes#398.
mpv was hardcoded to always consider the right Alt key as Alt Gr, but there
are parituclar combinations of platforms and keyboard layouts where it's more
convenient to treat the right Alt as a keyboard modifier just like the left
one.
Fixes#388
This is needed so that new processes (created with fork+exec) don't
inherit open files, which can be important for a number of reasons.
Since O_CLOEXEC is relatively new (POSIX.1-2008, before that Linux
specific), we #define it to 0 in io.h to prevent compilation errors on
older/crappy systems. At least this is the plan.
input.c creates a pipe. For that, add a mp_set_cloexec() function (which
is based on Weston's code in vo_wayland.c, but more correct). We could
use pipe2() instead, but that is Linux specific. Technically, we have a
race condition, but it won't matter.
pthreads should be available anywhere. Even if not, for environment
without threads a pthread wrapper could be provided that can't actually
start threads, thus disabling features that require threads.
Make pthreads mandatory in order to simplify build dependencies and to
reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe
we will use pthreads more in the future, and then it'd become a real
bother.)
This commit adds a new build system based on waf. configure and Makefile
are deprecated effective immediately and someday in the future they will be
removed (they are still available by running ./old-configure).
You can find how the choice for waf came to be in `DOCS/waf-buildsystem.rst`.
TL;DR: we couldn't get the same level of abstraction and customization with
other build systems we tried (CMake and autotools).
For guidance on how to build the software now, take a look at README.md
and the cross compilation guide.
CREDITS:
This is a squash of ~250 commits. Some of them are not by me, so here is the
deserved attribution:
- @wm4 contributed some Windows fixes, renamed configure to old-configure
and contributed to the bootstrap script. Also, GNU/Linux testing.
- @lachs0r contributed some Windows fixes and the bootstrap script.
- @Nikoli contributed a lot of testing and discovered many bugs.
- @CrimsonVoid contributed changes to the bootstrap script.
The configure followed 5 different convetions of defines because the next guy
always wanted to introduce a new better way to uniform it[1]. For an
hypothetic feature 'hurr' you could have had:
* #define HAVE_HURR 1 / #undef HAVE_DURR
* #define HAVE_HURR / #undef HAVE_DURR
* #define CONFIG_HURR 1 / #undef CONFIG_DURR
* #define HAVE_HURR 1 / #define HAVE_DURR 0
* #define CONFIG_HURR 1 / #define CONFIG_DURR 0
All is now uniform and uses:
* #define HAVE_HURR 1
* #define HAVE_DURR 0
We like definining to 0 as opposed to `undef` bcause it can help spot typos
and is very helpful when doing big reorganizations in the code.
[1]: http://xkcd.com/927/ related
When starting mpv with nohup, file descriptor 0 seems to be invalid for
some reason. (I'm not quite sure why it should be... /proc/pid/fd/0
seems to indicate it's just /dev/null, and using /dev/null explicitly
shows that it works just fine.)
select() will always immediately return, and this causes mpv to burn CPU
without reason. Fix this by treating it as EOF when read() returns
EBADF.
Also add EINVAL to this condition, because it seems like a good idea.
This seems to be a problem only in OS X 10.9. I guess they improved the
general speed of the Cocoa startup and suddenly mpv core takes more time
than the Cocoa thread to initialize.
Fixes#285
(hopefully!)
Now that talloc has been removed, the license can be switched back to
GPLv2+. Actually, there never was a GPLv2+ licensed MPlayer (fork or
not) until now, but removal of some GPLv2-only code makes this possible
now. Rewrite the Copyright file to explain the reasons for the licenses
MPlayer and forks use. The old Copyright file didn't contain anything
interesting anymore, and all information it contained is available at
other places in the source tree.
The reason for the license change itself is that it should improve
interoperability with differently licensed code in general.
This essentially reverts commit 1752808.
Remove the ifdef hell from mp_find_user_config_file(). Move the win32
specific code (for MinGW and Cygwin) to path-win.c. The behavior should
be about the same, but I can't be sure due to lack of testing and
because the old path.c code was hard to follow. (I expect those who care
about windows will fix things, should issues pop up - sorry.)
One difference is that the new code will always force MPV_HOME. It looks
like the old code preferred the mpv config dir in the exe dir if it
exists.
Also, make sure MP_PATH_MAX has enough space, even if the equivalent
wchar_t string is not 0-terminated with PATH_MAX (because apparently the
winapi doesn't require this). (Actually, maybe we should just kill all
uses of PATH_MAX/MP_PATH_MAX.)
This is a bit "hard", because getenv() returns a static string, and we
can't just return an allocated string. We also want getenv() to be
thread-safe if possible. (If the mpv core is going to be more threaded,
we sure do want the lower layers to be thread-safe as well.)
Turns out that these checks were for versions of OS X that mpv doesn't even
support anymore. So just remove the checks since they cause a deprecation
warning.
GetCurrentProcess() is deprecated on 10.9. Make a universal solution by
checking OS version number.
get_system_version() function is the recommended Apple way of getting the
OS version, since Gestalt is also deprecated (and does pretty much the same
thing anyway)
Updating HIDRemote.m to use a similar function would allow to get rid of the
2 other warnings.
I did commit 86c05655d by thinking `mpv` already removed the `mpv` from
argc/argv. It actually is still there, so the argc must be 1 to check for no
arguments.
Thanks to @Nyx0uf for pointing out the bug and for testing on 10.9!
File opening through Finder, apparently drops `--psn` arguments on Mavericks
and just uses no args. Modify the code to account for that case.
This wasn't tested on 10.9 itself (I don't have a paid dev account), but it
*should* work if I understood the problem correctly.
Pretty useful for people writing userscripts for web browsers. Links starting
with 'mpv://' are forwarded to the mpv OSX bundle. The leading 'mpv://' is
stripped from the recived url and the rest of the string is inserted as is in
the playlist.
This prevents keys to become stuck due to changing keyboard modifiers during
the key down. Not the prettiest approach but event `x11_common` does it like
this.
Fixes#210
Fixes reports of printing of garbage (or anything else) other than clearing
the status line to the end of line: the buffer returned by termcap_get
could get moved, and if that happened then these 3 caps pointed to garbage.
setupterm abort()s if it can't initialize the terminal and the last
parameter is NULL; handle setupterm errors and retry with "ansi" if
the TERM env var was unset.
Due to the termcap matching and the hardcoded fallbacks, the ESC keypress
has to be followed by another non-matching keypress (such as another ESC)
for it to be accepted. We drop the second ESC in case it was typed twice.
If the first character is not a valid UTF-8 start code nor is in termcap,
getch2 would enter an infinite loop. Always walk 1 byte in the UTF-8 case
unless it's a valid start code.
If we still haven't read the full key from the input but it's regardless a
unique match in the database, we could receive a NULL keycode from
keys_search (it's not a full match after all) and proceed to use it.
Don't disable the keycode matching code if we don't have termcap as we can
still match against the hardcoded sequences.
Still uses termcap, but uses terminfo for loading the termcap database if
possible. Adds configure test to find terminfo; skips the termcap test
if terminfo is found since terminfo provides termcap.
Use termcap completely for special keys; if we can't get it from termcap
and it isn't one of the known fallbacks, we ignore its specialness and
treat as a sequence of UTF-8 codes.
Further hardcoded fallbacks can be added by calling keys_push_once in
load_termcap; there is no limit to the amount of keys pushed.
Uses the "ke" and "ks" capabilities to start / exit application mode, which
is necessary on vt100 emulators (including screen, xterm and all terminals
that emulate either of those) to correctly receive arrow keys.
It's now possible to compile getch2 even without termcap, though it won't
be of much use since it'll be unable to detect special keys.
Converted to 4 spaces per tab, prettified some statements.
Since Windows Vista, when running at 144 DPI or higher with composition
switched on, applications that don't declare themselves to be DPI aware
are stretched by the window manager, kind of like low resolution apps in
OSX.
To avoid this, declare DPI awareness in the manifest. Since mpv is
practically resolution independent this shouldn't cause any trouble. The
'True/PM' value declares per-monitor DPI awareness in Windows 8.1, so
that the mpv isn't shrunk when moved from a high DPI screen to one with
a lower DPI.
Also, avoid compatibility shims by declaring compatibility with all
Windows versions from Vista to 8.1 and add the missing uiAccess
attribute to the requestedExecutionLevel element.
Not sure how this worked. Only af_export.c and tvi_v4l2.c were
using mmap, but they didn't include osdep/mmap.h or mmap_anon.h. In
any case, we trust that the target system is sufficiently POSIX
compliant if mmap is actually defined (as checked by configure).
Update Cocoa parts to remove usage of the mp_fifo internal API to send events
to the core and use the input context directly. This is to follow commits the
work in commits 70a8079c and d603e73c.
Recent work in the OS X parts of the code started using clang's support for
Obj-C's support for Literals and Subscripting. These particular language
features remove a lot of boilerplate code and allow to interact with
collections as consicely as one would do in scripting languages like Ruby or
Python.
Even if these are compiler features, Subscripting needs some runtime support.
This is provided with libarclite (coming with the compiler), but we need to
add the proper method definitions since the 10.7 SDK headers do not include
them. That is because 10.7 shipped before this language features.
This will cause some warnings when compiling with the 10.7 SDK because the
commit also redefines BOOL to make autoboxing/unboxing of BOOL literals to
work.
If you need to test this for whatever reason on 10.8, just pass in the correct
SDK to configure's extra cflags:
./configure --extra-cflags='-mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk'
Fixes#117
This was overlooked in the previous inplementation. Adding it required some
refactoring of the `handleKeyDown:` method in order to extract common parts
with `handleMediaKey:`.
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.
Media keys are pretty handy if you use mpv as a music player (yes I'm one of
those people that do).
These are the bindings (which lead to the same behaviour as iTunes):
* NX_KEYTYPE_PLAY -> MP_KEY_PLAY
* NX_KEYTYPE_FAST -> MP_KEY_NEXT
* NX_KEYTYPE_REWIND -> MP_KEY_PREV
I just handled these ones as the volume one would be pretty invasive. I could
maybe change it to increase the application's volume instead of system volume
only when mpv is frontmost (iTunes does this), but some users would probably
hate it.
Now that Cocoa's input handling is done on a separate thread from the playloop
it is ridicolously simple to have longer asynchronous sleeps when paused.
On OSX with Cocoa enabled keyDown events are now handled with
addLocalMonitorForEventsMatchingMask:handler:. This allows to respond to
events even when there is no VO initialized but the GUI is focused.
