By the way, its earlier (<= 0.8.6) incarnation were buggy.

By the way, the Win32 video outputs could probably go through some code
factorization. Don't ask me.

(Since we are always dealing with a pipe, it cannot return EINVAL)

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

Unbreaks start-up on WinCE.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

Pointed out by linkfanel.

Once the input main loop is done (or if input init fails), input
controls are not popped anyway. So the input callbacks are no-ops.
There is no point in postponing cleanup.

The only event that lock_and_wait can only wait for the end of the
interface event (safely). That is the only piece of state which is read
under the lock.

Also it is not possible to wait on a random object since (deprecated)
vlc_object_signal() is _not_ broadcasting the object condition variable.
In effect, VLC threads shall only wait on their own object (this is not
LUA-specific).

Ultimately, lock_and_wait is of barely any use, and in any case is now
poorly named (my fault for inventing vlc_object_lock_and_wait()). By the
way, it always returns true now.

commit. Thou I think it should invalidate current album art, so core would do
new search for it.

 Input manager now emits signal for album art and gives
 url to art itself, so CoverArt or Background-widgets don't
 need to parse it themself, and CoverArt don't need to use
 those callbacks. This ways both get same image too.