Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

This reverts commit 35fa551f.

Conflicts:

	configure.ac

The error value for mmap() is MAP_FAILED, which is not nul. But we
check for that case in Open() anyway.

This applies for plugin.cpp, vlccontrol2.cpp and persistpropbag.
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

- Ship the vlc module header zip.h
 (rename isn't needed once the file in ship)
- Detect minizip presence with pkgconfig
- if .pc not available, try to assume presence from unzip.h
- Move the zlib.h detection in one place (after pkgconfig macro)
 minizip in bundled within zlib in some distro
- Adds -lz in module that needs it in one place
- Prevent the compilation of libs/unzip if minizip is available
 (it shound't prevent this directory to be bundled with the sources)
Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>

Closing of filedescriptor to /dev/fbx does not remove the mmap'ed areas. A call to munmap() is needed for this.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Patch by jan-paul dinger (jpd at m2x dot nl).

This should really be a singleton or at least not built when you play only audio.

This reverts commit 1463e7cb.

Conflicts:

	modules/gui/qt4/components/controller.cpp
	modules/gui/qt4/components/controller_widget.hpp

According to https://bugzilla.mozilla.org/show_bug.cgi?id=455458
npupp.h has been renamed to npfunctions.h with libxul 1.9.1
Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

 * use psz_name when an item doesn't have a title
 * proper locking
 * little speed up

(thanks fenrir for the reviews)

Now, this should work safely, although it requires heavy polling.

This API is completely idiotic. By design, it requires (very active)
polling to work. Also, it is almost impossible to make it thread-safe.
Anyway, through violating a few constant pointers, we can fix half of
that. However, message item reference counting remains broken.

It was not thread-safe, and only used by ncurses (fixed earlier).

Changing the verbosity at that point is not thread-safe (and trying to
restore the value at ext is somwehat logically flawed). Luckily all the
standard <stdio.h> functions are thread-safe.

Signed-off-by: Rémi Denis-Courmont <rdenis@simphalempin.com>