[MPlayer-dev-eng] [PATCH] vo_macosx: process events with shared_buffer (and patch roundup)

[Adrian Stutz]

Well, it was bugging me. A call to NSConnection shouldn't trigger
window server's suspicion to get him to come out and flag MPlayer as
unresponsive. The OSX frameworks are layered and NSConnection is in
the Foundation framework and not in the AppKit one, where anything
related to gui applications and unresponsiveness resides (and is even
marked daemon-safe in an Apple TechNote).

After reading through everything Google could dig up, the fact that my
MacBook was affect while my desktop was not tipped me while searching
the MPlayer source: My MacBook has an infrared receiver, my desktop
has not.

Sure enough, digging through input/ar.c brought up a couple of Carbon
calls to check if MPlayer is the front process. Commenting them out
made MPlayer no longer be flagged unresponsive on my MacBook.
Reproduction is quite simple: Add "-noar" to the additional parameters
in Extended and MPlayer doesn't get flagged as unresponsive anymore.

Now, that doesn't make the solution any simpler, since there isn't any
easy replacement for the code in ar.c.

I currently see three options:

(1) Bite the bullet and add event processing to vo_corevideo even if
it's for fixing a bug in an unrelated part of MPlayer.

(2) The only proper way to inquire if MPlayer (or the frontend) is the
frontmost process seems to be in the vo. In case of vo_corevideo it
could return the state of its own window or the state of the frontend
through the NSConnection.

(3) Simply disable MPlayer's Apple Remote support and implement it in
the frontend.

Is there an interest in (2) for other parts of MPlayer? I guess it
could be implemented as a VOCTRL and shouldn't be too complex.

Greetings
Adrian