As the "descriptor" function is called with absolutely no libraries
loaded, even the built-in "require" function is not present at scan
time.
This closes #3453.

Note: this is a bit of a hack, but I prefer not to load any libs when
scanning the available extensions

Remove some useless debug, too

This reverts commit a9175056.

If the main interface does not contain any video, it has no business
with the video-on-top flag.

This presumptively fixes a probable race condition. For the umpteenth
time, never ever make any Qt4 UI call from the video output thread!!

The main interface went always-on-top when the video widget was created
but it failed to return to normal state when the video widget was
destroyed.

Unfortunately, according to the Qt4 documentation, changing the window
flags hides the window (until show() is called). So I guess there is no
way to toggle the on-top mode without the ugly blinking effect. Then,
try to minimize its occurences.

block_FifoWake does not work as I thought.

If false, the vout core will use a thread to dispatch key events.
It reimplement [cb72d26f] using a bit less code
and by adding support for multiple keys pressed in a row.
The thread is created only if needed.

This reverts commit cb72d26f.

This reverts commit a0c1d2cc.

This reverts commit 031dec33.

This reverts commit 4b435093.

We have the same bug in several outputs (SDL, AA, CACA), so lets make
the solution generic.

This is consistent with the current mouse filter, and how people tend
to interpret the horizontal and vertical words. Until now, VLC would
refer to the rotational axis direction rather than the direction of the
changed dimension.

Fixes: LB#568750

Close #3573
How can the size of a widget be bigger than the size of its parent window? Really weird Qt bug

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

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

It doesn't belong to the input.

Signed-off-by: Ilkka Ollakka <ileoo@videolan.org>
(commited with --author, no git-format patch was send to vlc-devel even if requested)

Currently, this is not used anywhere, but better have it for forward
compatibility. This is not as elegant as a dedicated libvlc function
call. But there is no other way to set a parameter before
libvlc_InternalInit() is called by libvlc_new(), short of changing the
libvlc_new() prototype (again). And that would probably be worse.

In theory, we should check that there is only one slash per token, but
it is not really dangerous.

First, we should not let user shoot themselves in the foot. But most
importantly, we need to validate the string as it is marked as a safe
option (especially CRLF there could be disastrous).

RFC2616 requires a space-separated list of names[/versions]

The new config value is duplicated, and the copy is stored to the
configuration. After the configuration R/W lock is released, we have no
warranty that another thread does not change the same configuration
item, and free our own copy. Admittedly, this is very unlikely.

Instead, we can simply pass the original string from the caller to the
callback - that one must remain valid through the config_PutPsz()
function call by definition.