Previously FreeBSD had an optional port that installed /etc/os-release
so it was already available on many FreeBSD systems, but os-release is
now provided by the base system and will be universally available.
The proposed way to handle plugin distribution
through Flatpak depends on these directories to
be read. It goes as follows:
1. Flatpak's extension point merges the 'lib'
and 'share' directories at /app/plugin
2. Plugins prefix their install paths in the
Flatpak manifest to /app/plugins/<plugin name>
3. OBS Studio lists /app/plugin as one of the
search paths in OBS Studio code
This commit implements the third step of this
process, which is the only one that actually
involves OBS Studio itself.
With that, it is possible to distribute plugins
as Flatpak extensions, which in turn allows them
to be listed at app stores such as GNOME Software,
elementary's app store, and KDE's Discover.
Related: https://github.com/flathub/com.obsproject.Studio/issues/135
This is a Unix-specific code. The only available platforms
at this point are the X11/GLX and X11/EGL platforms.
The concept of a platform display is also introduced. Again,
the only display that is set right now is the X11 display.
Currently, obs-nix.c is highly tied to the X11 display
server. It includes X11 headers directly, and make use
of X11 functions. Most of the code inside obs-nix.c that
is X11-specific is related to hotkeys handling.
Introduce a new vtable for hotkeys callbacks, that will
used by X11 and Wayland to expose their specific routines.
In this commit, only the X11 hotkeys vtable is implemented.
Move all the X11-specific code to obs-nix-x11.c, and add
a new function to retrieve the X11 hotkeys vtable.
Add the content of the XDG_SESSION_TYPE environment variable to
the output log if it is set. This is usually set on modern Linux
distributions and typically carry either "x11" or "wayland" when
run from a desktop environment.
This is independent from the QT_QPA_PLATFORM environment variable
which would allow OBS Studio to run inside a wayland session. The
session type it runs on does have an implication on the behavior of
some plugins like screen and window capture. So having this
information exposed here is extremely helpful for diagnosing
issues.
Code submissions have continually suffered from formatting
inconsistencies that constantly have to be addressed. Using
clang-format simplifies this by making code formatting more consistent,
and allows automation of the code formatting so that maintainers can
focus more on the code itself instead of code formatting.
Rename "Processor" to "CPU Name" and place it before the number of
cores. Log free RAM for *nix. Log CPU Speed on Linux and FreeBSD. Unify
processor logging on Linux and FreeBSD. Get physical and logical cores
on *nix.
Use the new os_get_logical_cores and os_get_physical_cores function from
commits 6fc74d6 and e4a64f0 to get CPU core counts on *nix systems.
The screen index returned from XDefaultScreen is 0-based, and we were
decrementing it before the check to see if it had reached 0 rather than
after, so in the default_screen function it would always end up getting
either the wrong screen or no screen.
When xcb_query_pointer and xcb_query_pointer_reply was called with no
valid screen, it would fail with an error, thus making it so that the
mouse buttons could not be properly captured as hotkeys.
Implement the log_processor_info function on bsd and add ifdefs to only
build the implementation specific to the platform.
Also add an ifdef around the call to that function to make sure it will
only be called on platforms where it is actually implemented.
Split the function logging the processor information on nix into two
parts. The part logging the number of logical cores is portable and
works on all systems that support POSIX.1 while the other part is
specific to linux.
Add definition on FreeBSD to enable getline in stdio, as it is not
(yet ?) available by default. According to the manpage getline was a
GNU extension but was standardized in POSIX.1-2008.
This reverts commit 92d800cc18, reversing
changes made to 35a4acede0.
These commits were originally added to allow multiple user interfaces to
use the same plugins, but I soon realized that multiple user interfaces
can use multiple libobs versions, so each user interface should have its
own set of plugins to manage. Some user interfaces may not wish to use
certain plugins anyway, so this fixes that issue as well.
As stated in the sysinfo manpage the totalram field in the sysinfo
structure is in mem_unit sizes since Linux 2.3.23. To get the actual
memory in the system the totalram value has to be multiplied with the
mem_unit size.
Changed API:
- char *obs_find_plugin_file(const char *sub_path);
Changed to: char *obs_module_file(const char *file);
Cahnge it so you no longer need to specify a sub-path such as:
obs_find_plugin_file("module_name/file.ext")
Instead, now automatically handle the module data path so all you need
to do is:
obs_module_file("file.ext")
- int obs_load_module(const char *name);
Changed to: int obs_open_module(obs_module_t *module,
const char *path,
const char *data_path);
bool obs_init_module(obs_module_t module);
Change the module loading API so that if the front-end chooses, it can
load modules directly from a specified path, and associate a data
directory with it on the spot.
The module will not be initialized immediately; obs_init_module must
be called on the module pointer in order to fully initialize the
module. This is done so a module can be disabled by the front-end if
the it so chooses.
New API:
- void obs_add_module_path(const char *bin, const char *data);
These functions allow you to specify new module search paths to add,
and allow you to search through them, or optionally just load all
modules from them. If the string %module% is included, it will
replace it with the module's name when that string is used as a
lookup. Data paths are now directly added to the module's internal
storage structure, and when obs_find_module_file is used, it will look
up the pointer to the obs_module structure and get its data directory
that way.
Example:
obs_add_module_path("/opt/obs/my-modules/%module%/bin",
"/opt/obs/my-modules/%module%/data");
This would cause it to additionally look for the binary of a
hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so
(or libfoo.so), and then look for the data in
/opt/obs/my-modules/foo/data.
This gives the front-end more flexibility for handling third-party
plugin modules, or handling all plugin modules in a custom way.
- void obs_find_modules(obs_find_module_callback_t callback, void
*param);
This searches the existing paths for modules and calls the callback
function when any are found. Useful for plugin management and custom
handling of the paths by the front-end if desired.
- void obs_load_all_modules(void);
Search through the paths and both loads and initializes all modules
automatically without custom handling.
- void obs_enum_modules(obs_enum_module_callback_t callback,
void *param);
Enumerates currently opened modules.
