Lua is an important part of VLC and abusing misc has gone a bit too far...

Signed-off-by: Laurent Aimar <fenrir@videolan.org>

Signed-off-by: Laurent Aimar <fenrir@videolan.org>

Signed-off-by: Laurent Aimar <fenrir@videolan.org>

Depending whether they are VLC specific or not

SD and extensions are very visible inside the interfaces,
and we are, considered "éditeurs", on those.
Therefore, we do not distribute those where we don't know the legal
state.
Having them in the git, is not considered distribution, (yet).

It only worked for non-ES OpenGL and if the libGL development files
were installed (otherwise "libGL.so" does not exist). So let Mesa fix
their bugs and stop caring about them:
https://bugs.freedesktop.org/show_bug.cgi?id=34476

In the mean time, you can use VLC and EGL with:

 # LD_PRELOAD=/usr/lib/libGL.so vlc

xcb_window can be compiled without libxcb-keysyms nowadays, so this
check was rather useless.

Special credits to Debian for releasing Squeeze.

The comment seems to be irrelevant (the variable is called marq-color and not marq-col).

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

 * use a poll() based model instead of msleep()
 * Use input events to detect when the input thread stops playback
 * Use an enum for mpris playback statuses instead of hardcoded values

v1 does not work and v2 does not compile but nevermind...

This is needed for global hotkeys. In the best of worlds, I think the
global hotkey plugins would directly get the list of keycodes to grab
using a dedicated plugin type. This would avoid the need to replicate
hotkey configuration parsing. But it would need some more work.

Why can't Mesa people link their shared objects correctly!?

This suffers from the same limitations as the EGL output (no resize and
mouse events) currently and should be considered work in progress.

This is purely a syntactical change to share the opengl.c code.
This commit does not actually make use of the vlc_gl_Create().

This API is abstracted away from the video output. In a way, this goes
back to the previous opengl provider API, except that:
 - it is really independent of the video output,
 - it supports GL ES explicitly.