GitLab

We have enough static locks in libvlc, I think: the
configuration R/W lock, the module bank mutex, the system-specific
initialization mutex, the message subscription R/W lock, the sets
of mutexes for initializations of specific libraries, the LibVLC
thread variable mutex, the configuration file mutex, the PRNG mutex,
the object pipe mutex, the object name mutex, the dialog provider
mutex, the interface module registration mutex, the OSD mutex, the
VLM mutex, the HTTP hosts mutex and the OSD mutex...

In other words, the message callbacks are now shared across all LibVLC
instances. That is a requirement to enable:
 - LibVLC applications to catch messages during LibVLC init/deinit,
 - emitting log messages when no VLC object point is available.

That makes no difference for VLC interfaces, since there is only one
LibVLC instances in a VLC process.

Use NULL rather than a static string as the default.
module_get_object() deals with this situation.

Not only is an extra console obnoxious, but freopen() crashes.

darwin relied on argv[0] as a fallback to retrieve executable name,
but this can't work anymore as:
- libvlc_new() can be given anything as argc/argv
- libvlc_new() inserts "libvlc" at position 0 anyway

Identity is not a method but a property
"" is not a valid object path

 * Connect to the other instance using the mpris2 bus name,
   object path and interfaces so that the one-instance mode
   works with the mpris2-enabled dbus control interface

I don't this abomination to leak through the stable LibVLC interface.
To link statically, modules should be linked into LibVLC instead.

And then, there is no need to reintroduce the old "builtin" vlc-config
type if all modules are built the same. In prehistoric times, the
distinction was needed because some modules were static and some not.

Close #3093

Most of the code churn in this commit comes from converting from void *
to uintptr.

We cannot fully privatize this, as the global hotkeys plugin read the
list of actions through the public LibVLC instance pointer.

...rather than with a command line option. This enables extending the
set of plugins paths globally, for all LibVLC applications.

Using an environment variable seems more logical than a command line
option considering that the module bank is shared by all VLC instances
in the process. In other words, it did not belong as a parameter to
libvlc_new().

The configuration is simplified a bit.
Multiple keys per action will be easier to add.

N.B.: this commit breaks global hotkeys setup and hotkey prefs

Fixes Debian bug #600269

ML holds some PL resources

This avoids iterating through all config items of each modules. On my
system, this cuts the vlcrc load time in half, and is also far simpler.
The loader is essentially ignoring the config section, which reflects
the architectural "limitation" of the VLC configuration.

This also avoids loosing settings during VLC upgrades if an option moves
from one module to another one (which did happen in the past).