[v10,02/13] config: Introduce global runtime configuration

23565 diff mbox series

Currently, libcamera can be configured in runtime using several
environment variables.  With introducing more and more variables, this
mechanism reaches its limits.  It would be simpler and more flexible if
it was possible to configure libcamera in a single file.

For example, there was a request to define pipeline precedence in
runtime.  We want to compile in multiple pipelines, in order to have
them accessible within single packages in distributions.  And then being
able to select among the pipelines manually as needed based on the
particular hardware or operating system environment.  Having the
configuration file then allows easy switching between hardware, GPU or
CPU IPAs.  Another possible use case is tuning image output, especially
with software ISP, to user liking.  For example, some users may prefer
higher contrast without the need to use the corresponding knobs, if
present at all, in every application.  The configuration file can also
be used to enable or disable experimental features and avoid the need to
track local patches changing configuration options hard-wired in the
code when working on new features.

This patch introduces basic support for configuration files.
GlobalConfiguration class reads, stores and accesses the configuration.
GlobalConfiguration instances are meant to be stored to and accessed
from instances of another class, preferably from a single instance.
GlobalConfiguration is defined in base because it will be accessed from
code in base, e.g. logging.

libcamera configuration can be specified using a system-wide
configuration file or a user configuration file.  The user configuration
file takes precedence if present.  There is currently no way to merge
multiple configuration files, the one found is used as the only
configuration file.  If no configuration file is present, nothing
changes to the current libcamera behavior (except for some log
messages related to configuration file lookup).

The configuration file is a YAML file.  We already have a mechanism for
handling YAML configuration files in libcamera and the given
infrastructure can be reused for the purpose.  However, the
configuration type is abstracted to make contingent future change of the
underlying class easier while retaining (most of) the original API.

The configuration is versioned.  This has currently no particular
meaning but is likely to have its purpose in future, especially once
configuration validation is introduced.

The configuration YAML file looks as follows:

  ---
  version: 1
  configuration:
    WHATEVER CONFIGURATION NEEDED

This patch introduces just the basic idea.  Actually using the
configuration in the corresponding places (everything what is currently
configurable via environment variables should be configurable in the
file configuration) and other enhancements are implemented in the
followup patches.

Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
---
 .../libcamera/internal/global_configuration.h |  34 ++++
 include/libcamera/internal/meson.build        |   1 +
 src/libcamera/base/global_configuration.cpp   | 150 ++++++++++++++++++
 src/libcamera/base/meson.build                |   1 +
 4 files changed, 186 insertions(+)
 create mode 100644 include/libcamera/internal/global_configuration.h
 create mode 100644 src/libcamera/base/global_configuration.cpp

Hi Milan,

Thank you for the patch.

On Mon, Jun 16, 2025 at 10:47:20AM +0200, Milan Zamazal wrote:
> Currently, libcamera can be configured in runtime using several
> environment variables.  With introducing more and more variables, this
> mechanism reaches its limits.  It would be simpler and more flexible if
> it was possible to configure libcamera in a single file.
> 
> For example, there was a request to define pipeline precedence in
> runtime.  We want to compile in multiple pipelines, in order to have
> them accessible within single packages in distributions.  And then being
> able to select among the pipelines manually as needed based on the
> particular hardware or operating system environment.  Having the
> configuration file then allows easy switching between hardware, GPU or
> CPU IPAs.  Another possible use case is tuning image output, especially
> with software ISP, to user liking.  For example, some users may prefer
> higher contrast without the need to use the corresponding knobs, if
> present at all, in every application.

That's an interesting use case, but I don't think it necessarily belong
to the global configuration file. In the context of a desktop
distribution where libcamera is used through pipewire, user preferences
are I think best handled through pipewire. This isn't a topic that needs
to be decided now, I foresee lots of interesting discussions in the
future about what should go to the configuration file and what
shouldn't.

> The configuration file can also
> be used to enable or disable experimental features and avoid the need to
> track local patches changing configuration options hard-wired in the
> code when working on new features.
> 
> This patch introduces basic support for configuration files.
> GlobalConfiguration class reads, stores and accesses the configuration.
> GlobalConfiguration instances are meant to be stored to and accessed
> from instances of another class, preferably from a single instance.
> GlobalConfiguration is defined in base because it will be accessed from
> code in base, e.g. logging.

As mentioned in the review of 01/13, moving YamlParser to base is
problematic. Let's see in the appropriate patch if we can configure the
logger without having configuration file support in base.

> libcamera configuration can be specified using a system-wide
> configuration file or a user configuration file.  The user configuration
> file takes precedence if present.  There is currently no way to merge
> multiple configuration files, the one found is used as the only
> configuration file.

Is this an issue ? I'm wondering if we need a default configuration in
/usr/share/libcamera and a system-specific override in /etc/libcamera
(or somewhere else).

> If no configuration file is present, nothing
> changes to the current libcamera behavior (except for some log
> messages related to configuration file lookup).
> 
> The configuration file is a YAML file.  We already have a mechanism for
> handling YAML configuration files in libcamera and the given
> infrastructure can be reused for the purpose.  However, the
> configuration type is abstracted to make contingent future change of the
> underlying class easier while retaining (most of) the original API.

What changes are you expecting ?

> 
> The configuration is versioned.  This has currently no particular
> meaning but is likely to have its purpose in future, especially once
> configuration validation is introduced.
> 
> The configuration YAML file looks as follows:
> 
>   ---
>   version: 1
>   configuration:
>     WHATEVER CONFIGURATION NEEDED
> 
> This patch introduces just the basic idea.  Actually using the
> configuration in the corresponding places (everything what is currently
> configurable via environment variables should be configurable in the
> file configuration) and other enhancements are implemented in the
> followup patches.

I probably won't have many comments on this patch yet, I'll review the
remaining of the series first to see how the class gets used. Skimming
through the series though, I was expecting this patch to introduce a
fully-fledged class, but I see that quite a few extensions to the class
are spread in other patches. I don't mind too much either way though.

> 
> Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
> ---
>  .../libcamera/internal/global_configuration.h |  34 ++++
>  include/libcamera/internal/meson.build        |   1 +
>  src/libcamera/base/global_configuration.cpp   | 150 ++++++++++++++++++
>  src/libcamera/base/meson.build                |   1 +
>  4 files changed, 186 insertions(+)
>  create mode 100644 include/libcamera/internal/global_configuration.h
>  create mode 100644 src/libcamera/base/global_configuration.cpp
> 
> diff --git a/include/libcamera/internal/global_configuration.h b/include/libcamera/internal/global_configuration.h
> new file mode 100644
> index 000000000..8d0410ac2
> --- /dev/null
> +++ b/include/libcamera/internal/global_configuration.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: LGPL-2.1-or-later */
> +/*
> + * Copyright (C) 2024-2025 Red Hat, inc.
> + *
> + * Global configuration handling
> + */
> +
> +#pragma once
> +
> +#include <filesystem>
> +
> +#include "libcamera/internal/yaml_parser.h"
> +
> +namespace libcamera {
> +
> +class GlobalConfiguration
> +{
> +public:
> +	using Configuration = const YamlObject &;
> +
> +	GlobalConfiguration();
> +
> +	unsigned int version() const;
> +	Configuration configuration() const;
> +
> +private:
> +	bool loadFile(const std::filesystem::path &fileName);
> +	void load();
> +	Configuration get() const;
> +
> +	std::unique_ptr<YamlObject> yamlConfiguration;

Missing trailing underscore.

> +};
> +
> +} /* namespace libcamera */
> diff --git a/include/libcamera/internal/meson.build b/include/libcamera/internal/meson.build
> index 33f318b2b..951bfee49 100644
> --- a/include/libcamera/internal/meson.build
> +++ b/include/libcamera/internal/meson.build
> @@ -22,6 +22,7 @@ libcamera_internal_headers = files([
>      'dma_buf_allocator.h',
>      'formats.h',
>      'framebuffer.h',
> +    'global_configuration.h',

This would belong to include/libcamera/base/ if global_configuration.cpp
is in base too.

>      'ipa_data_serializer.h',
>      'ipa_manager.h',
>      'ipa_module.h',
> diff --git a/src/libcamera/base/global_configuration.cpp b/src/libcamera/base/global_configuration.cpp
> new file mode 100644
> index 000000000..1ddf5bc33
> --- /dev/null
> +++ b/src/libcamera/base/global_configuration.cpp
> @@ -0,0 +1,150 @@
> +/* SPDX-License-Identifier: LGPL-2.1-or-later */
> +/*
> + * Copyright (C) 2024-2025 Red Hat, inc.
> + *
> + * Global configuration handling
> + */
> +
> +#include "libcamera/internal/global_configuration.h"
> +
> +#include <filesystem>
> +#include <string_view>
> +#include <sys/types.h>
> +
> +#include <libcamera/base/file.h>
> +#include <libcamera/base/log.h>
> +#include <libcamera/base/utils.h>
> +
> +#include "libcamera/internal/yaml_parser.h"
> +
> +namespace libcamera {
> +
> +namespace {
> +const std::vector<std::filesystem::path>
> +	globalConfigurationFiles = {
> +		std::filesystem::path(LIBCAMERA_SYSCONF_DIR) / "configuration.yaml",

Given that distributions install libcamera with prefix set to /usr, this
would be /usr/etc/libcamera/configuration.yaml, which is not a valid
location according to
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html.

> +		std::filesystem::path("/etc/libcamera/configuration.yaml"),
> +	};

You can write

const std::vector<std::filesystem::path> globalConfigurationFiles = {
	std::filesystem::path(LIBCAMERA_SYSCONF_DIR) / "configuration.yaml",
	std::filesystem::path("/etc/libcamera/configuration.yaml"),
};

And you could move this to a static const variable to
GlobalConfiguration::load(), the only place where it is used. But
looking at the rest of the series, globalConfigurationFiles becomes
unused somewhere, and should be dropped in the corresponding patch.

> +}
> +
> +LOG_DEFINE_CATEGORY(Configuration)
> +
> +/**
> + * \class GlobalConfiguration
> + * \brief Support for global libcamera configuration
> + *
> + * The configuration file is a YAML file and the configuration itself is stored
> + * under `configuration' top-level item.
> + *
> + * The configuration file is looked up in user's home directory first and if it
> + * is not found then in system-wide configuration directories. If multiple
> + * configuration files exist then only the first one found is used and no
> + * configuration merging is performed.
> + */
> +
> +bool GlobalConfiguration::loadFile(const std::filesystem::path &fileName)
> +{
> +	File file(fileName);
> +	if (!file.exists()) {
> +		return false;
> +	}

No need for curly braces.

> +
> +	if (!file.open(File::OpenModeFlag::ReadOnly)) {
> +		LOG(Configuration, Warning)
> +			<< "Failed to open configuration file " << fileName;
> +		return true;
> +	}
> +
> +	auto root = YamlParser::parse(file);

Maybe

	yamlConfiguration_ = YamlParser::parse(file);

?

> +	if (!root) {
> +		LOG(Configuration, Warning)
> +			<< "Failed to parse configuration file " << fileName;
> +		return true;
> +	}
> +	yamlConfiguration = std::move(root);
> +
> +	return true;
> +}
> +
> +void GlobalConfiguration::load()
> +{
> +	std::filesystem::path userConfigurationDirectory;
> +	char *xdgConfigHome = utils::secure_getenv("XDG_CONFIG_HOME");

const

> +	if (xdgConfigHome) {
> +		userConfigurationDirectory = xdgConfigHome;
> +	} else {
> +		const char *home = utils::secure_getenv("HOME");
> +		if (home)
> +			userConfigurationDirectory =
> +				std::filesystem::path(home) / ".config";
> +	}
> +
> +	if (!userConfigurationDirectory.empty()) {
> +		std::filesystem::path user_configuration_file =

camelCase

> +			userConfigurationDirectory / "libcamera" / "configuration.yaml";
> +		if (loadFile(user_configuration_file))
> +			return;

If the file exists but can't be loaded, should we make it a fatal error
? Continuing by ignoring malformed configuration files means we'll run
with a configuration different from what the user expects.

> +	}
> +
> +	for (const auto &path : globalConfigurationFiles)
> +		if (loadFile(path))
> +			return;

Please use curly braces for the outer scope.

> +}
> +
> +GlobalConfiguration::Configuration GlobalConfiguration::get() const
> +{
> +	return *yamlConfiguration;

I think you can drop this private function and access yamlConfiguration_
directly internally.

> +}
> +
> +/**
> + * \brief Initialize the global configuration
> + */
> +GlobalConfiguration::GlobalConfiguration()
> +{
> +	load();
> +}
> +
> +/**
> + * \typedef GlobalConfiguration::Configuration
> + * \brief Type representing global libcamera configuration
> + *
> + * All code outside GlobalConfiguration must use this type declaration and not
> + * the underlying type.

What's the reason for that ?

> + */
> +
> +/**
> + * \brief Return configuration version
> + *
> + * The version is (optionally) declared in the configuration file in the
> + * top-level section `version', alongside `configuration'. This has currently no
> + * real use but may be needed in future if configuration incompatibilities
> + * occur.
> + *
> + * \return Configuration version as declared in the configuration file or 0 if
> + * no version is declared there
> + */
> +unsigned int GlobalConfiguration::version() const
> +{
> +	return get()["version"].get<unsigned int>().value_or(0);
> +}
> +
> +/**
> + * \brief Return libcamera global configuration
> + *
> + * This returns the whole configuration stored in the top-level section
> + * `configuration' of the YAML configuration file.
> + *
> + * The requested part of the configuration can be accessed using \a YamlObject
> + * methods.
> + *
> + * \note \a YamlObject type itself shouldn't be used in type declarations to
> + * avoid trouble if we decide to change the underlying data objects in future.
> + *
> + * \return The whole configuration section
> + */
> +GlobalConfiguration::Configuration GlobalConfiguration::configuration() const
> +{
> +	return get()["configuration"];
> +}
> +
> +} /* namespace libcamera */
> diff --git a/src/libcamera/base/meson.build b/src/libcamera/base/meson.build
> index 94843eb95..4c0032845 100644
> --- a/src/libcamera/base/meson.build
> +++ b/src/libcamera/base/meson.build
> @@ -16,6 +16,7 @@ libcamera_base_internal_sources = files([
>      'event_dispatcher_poll.cpp',
>      'event_notifier.cpp',
>      'file.cpp',
> +    'global_configuration.cpp',
>      'log.cpp',
>      'memfd.cpp',
>      'message.cpp',

Hi

2025. 06. 17. 0:29 keltezéssel, Laurent Pinchart írta:
> Hi Milan,
> 
> Thank you for the patch.
> 
> On Mon, Jun 16, 2025 at 10:47:20AM +0200, Milan Zamazal wrote:
>> Currently, libcamera can be configured in runtime using several
>> environment variables.  With introducing more and more variables, this
>> mechanism reaches its limits.  It would be simpler and more flexible if
>> it was possible to configure libcamera in a single file.
>>
>> For example, there was a request to define pipeline precedence in
>> runtime.  We want to compile in multiple pipelines, in order to have
>> them accessible within single packages in distributions.  And then being
>> able to select among the pipelines manually as needed based on the
>> particular hardware or operating system environment.  Having the
>> configuration file then allows easy switching between hardware, GPU or
>> CPU IPAs.  Another possible use case is tuning image output, especially
>> with software ISP, to user liking.  For example, some users may prefer
>> higher contrast without the need to use the corresponding knobs, if
>> present at all, in every application.
> 
> That's an interesting use case, but I don't think it necessarily belong
> to the global configuration file. In the context of a desktop
> distribution where libcamera is used through pipewire, user preferences
> are I think best handled through pipewire. This isn't a topic that needs
> to be decided now, I foresee lots of interesting discussions in the
> future about what should go to the configuration file and what
> shouldn't.
> 
>> The configuration file can also
>> be used to enable or disable experimental features and avoid the need to
>> track local patches changing configuration options hard-wired in the
>> code when working on new features.
>>
>> This patch introduces basic support for configuration files.
>> GlobalConfiguration class reads, stores and accesses the configuration.
>> GlobalConfiguration instances are meant to be stored to and accessed
>> from instances of another class, preferably from a single instance.
>> GlobalConfiguration is defined in base because it will be accessed from
>> code in base, e.g. logging.
> 
> As mentioned in the review of 01/13, moving YamlParser to base is
> problematic. Let's see in the appropriate patch if we can configure the
> logger without having configuration file support in base.
> 
>> libcamera configuration can be specified using a system-wide
>> configuration file or a user configuration file.  The user configuration
>> file takes precedence if present.  There is currently no way to merge
>> multiple configuration files, the one found is used as the only
>> configuration file.
> 
> Is this an issue ? I'm wondering if we need a default configuration in
> /usr/share/libcamera and a system-specific override in /etc/libcamera
> (or somewhere else).
> 
>> If no configuration file is present, nothing
>> changes to the current libcamera behavior (except for some log
>> messages related to configuration file lookup).
>>
>> The configuration file is a YAML file.  We already have a mechanism for
>> handling YAML configuration files in libcamera and the given
>> infrastructure can be reused for the purpose.  However, the
>> configuration type is abstracted to make contingent future change of the
>> underlying class easier while retaining (most of) the original API.
> 
> What changes are you expecting ?
> 
>>
>> The configuration is versioned.  This has currently no particular
>> meaning but is likely to have its purpose in future, especially once
>> configuration validation is introduced.
>>
>> The configuration YAML file looks as follows:
>>
>>    ---
>>    version: 1
>>    configuration:
>>      WHATEVER CONFIGURATION NEEDED
>>
>> This patch introduces just the basic idea.  Actually using the
>> configuration in the corresponding places (everything what is currently
>> configurable via environment variables should be configurable in the
>> file configuration) and other enhancements are implemented in the
>> followup patches.
> 
> I probably won't have many comments on this patch yet, I'll review the
> remaining of the series first to see how the class gets used. Skimming
> through the series though, I was expecting this patch to introduce a
> fully-fledged class, but I see that quite a few extensions to the class
> are spread in other patches. I don't mind too much either way though.
> 
>>
>> Signed-off-by: Milan Zamazal <mzamazal@redhat.com>
>> ---
>>   .../libcamera/internal/global_configuration.h |  34 ++++
>>   include/libcamera/internal/meson.build        |   1 +
>>   src/libcamera/base/global_configuration.cpp   | 150 ++++++++++++++++++
>>   src/libcamera/base/meson.build                |   1 +
>>   4 files changed, 186 insertions(+)
>>   create mode 100644 include/libcamera/internal/global_configuration.h
>>   create mode 100644 src/libcamera/base/global_configuration.cpp
>>
>> diff --git a/include/libcamera/internal/global_configuration.h b/include/libcamera/internal/global_configuration.h
>> new file mode 100644
>> index 000000000..8d0410ac2
>> --- /dev/null
>> +++ b/include/libcamera/internal/global_configuration.h
>> @@ -0,0 +1,34 @@
>> +/* SPDX-License-Identifier: LGPL-2.1-or-later */
>> +/*
>> + * Copyright (C) 2024-2025 Red Hat, inc.
>> + *
>> + * Global configuration handling
>> + */
>> +
>> +#pragma once
>> +
>> +#include <filesystem>
>> +
>> +#include "libcamera/internal/yaml_parser.h"
>> +
>> +namespace libcamera {
>> +
>> +class GlobalConfiguration
>> +{
>> +public:
>> +	using Configuration = const YamlObject &;
>> +
>> +	GlobalConfiguration();
>> +
>> +	unsigned int version() const;
>> +	Configuration configuration() const;
>> +
>> +private:
>> +	bool loadFile(const std::filesystem::path &fileName);
>> +	void load();
>> +	Configuration get() const;
>> +
>> +	std::unique_ptr<YamlObject> yamlConfiguration;
> 
> Missing trailing underscore.
> 
>> +};
>> +
>> +} /* namespace libcamera */
>> diff --git a/include/libcamera/internal/meson.build b/include/libcamera/internal/meson.build
>> index 33f318b2b..951bfee49 100644
>> --- a/include/libcamera/internal/meson.build
>> +++ b/include/libcamera/internal/meson.build
>> @@ -22,6 +22,7 @@ libcamera_internal_headers = files([
>>       'dma_buf_allocator.h',
>>       'formats.h',
>>       'framebuffer.h',
>> +    'global_configuration.h',
> 
> This would belong to include/libcamera/base/ if global_configuration.cpp
> is in base too.
> 
>>       'ipa_data_serializer.h',
>>       'ipa_manager.h',
>>       'ipa_module.h',
>> diff --git a/src/libcamera/base/global_configuration.cpp b/src/libcamera/base/global_configuration.cpp
>> new file mode 100644
>> index 000000000..1ddf5bc33
>> --- /dev/null
>> +++ b/src/libcamera/base/global_configuration.cpp
>> @@ -0,0 +1,150 @@
>> +/* SPDX-License-Identifier: LGPL-2.1-or-later */
>> +/*
>> + * Copyright (C) 2024-2025 Red Hat, inc.
>> + *
>> + * Global configuration handling
>> + */
>> +
>> +#include "libcamera/internal/global_configuration.h"
>> +
>> +#include <filesystem>
>> +#include <string_view>
>> +#include <sys/types.h>
>> +
>> +#include <libcamera/base/file.h>
>> +#include <libcamera/base/log.h>
>> +#include <libcamera/base/utils.h>
>> +
>> +#include "libcamera/internal/yaml_parser.h"
>> +
>> +namespace libcamera {
>> +
>> +namespace {
>> +const std::vector<std::filesystem::path>
>> +	globalConfigurationFiles = {
>> +		std::filesystem::path(LIBCAMERA_SYSCONF_DIR) / "configuration.yaml",
> 
> Given that distributions install libcamera with prefix set to /usr, this
> would be /usr/etc/libcamera/configuration.yaml, which is not a valid
> location according to
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html.

Looks good to me. `LIBCAMERA_SYSCONF_DIR` becomes `/etc/libcamera/` if you set `-D prefix=/usr`.
See https://mesonbuild.com/Release-notes-for-0-44-0.html#prefixdependent-defaults-for-sysconfdir-localstatedir-and-sharedstatedir

I would probably change the lookup order as follows:

   - LIBCAMERA_SYSCONF_DIR (/etc/libcamera usually)
   - LIBCAMERA_DATA_DIR (/usr/share/libcamera usually)

I am not sure that we want to hard-code "/etc/libcamera" there.


Regards,
Barnabás Pőcze

> 
>> +		std::filesystem::path("/etc/libcamera/configuration.yaml"),
>> +	};
> 
> You can write
> 
> const std::vector<std::filesystem::path> globalConfigurationFiles = {
> 	std::filesystem::path(LIBCAMERA_SYSCONF_DIR) / "configuration.yaml",
> 	std::filesystem::path("/etc/libcamera/configuration.yaml"),
> };
> 
> And you could move this to a static const variable to
> GlobalConfiguration::load(), the only place where it is used. But
> looking at the rest of the series, globalConfigurationFiles becomes
> unused somewhere, and should be dropped in the corresponding patch.
> 
>> +}
>> +
>> +LOG_DEFINE_CATEGORY(Configuration)
>> +
>> +/**
>> + * \class GlobalConfiguration
>> + * \brief Support for global libcamera configuration
>> + *
>> + * The configuration file is a YAML file and the configuration itself is stored
>> + * under `configuration' top-level item.
>> + *
>> + * The configuration file is looked up in user's home directory first and if it
>> + * is not found then in system-wide configuration directories. If multiple
>> + * configuration files exist then only the first one found is used and no
>> + * configuration merging is performed.
>> + */
>> +
>> +bool GlobalConfiguration::loadFile(const std::filesystem::path &fileName)
>> +{
>> +	File file(fileName);
>> +	if (!file.exists()) {
>> +		return false;
>> +	}
> 
> No need for curly braces.
> 
>> +
>> +	if (!file.open(File::OpenModeFlag::ReadOnly)) {
>> +		LOG(Configuration, Warning)
>> +			<< "Failed to open configuration file " << fileName;
>> +		return true;
>> +	}
>> +
>> +	auto root = YamlParser::parse(file);
> 
> Maybe
> 
> 	yamlConfiguration_ = YamlParser::parse(file);
> 
> ?
> 
>> +	if (!root) {
>> +		LOG(Configuration, Warning)
>> +			<< "Failed to parse configuration file " << fileName;
>> +		return true;
>> +	}
>> +	yamlConfiguration = std::move(root);
>> +
>> +	return true;
>> +}
>> +
>> +void GlobalConfiguration::load()
>> +{
>> +	std::filesystem::path userConfigurationDirectory;
>> +	char *xdgConfigHome = utils::secure_getenv("XDG_CONFIG_HOME");
> 
> const
> 
>> +	if (xdgConfigHome) {
>> +		userConfigurationDirectory = xdgConfigHome;
>> +	} else {
>> +		const char *home = utils::secure_getenv("HOME");
>> +		if (home)
>> +			userConfigurationDirectory =
>> +				std::filesystem::path(home) / ".config";
>> +	}
>> +
>> +	if (!userConfigurationDirectory.empty()) {
>> +		std::filesystem::path user_configuration_file =
> 
> camelCase
> 
>> +			userConfigurationDirectory / "libcamera" / "configuration.yaml";
>> +		if (loadFile(user_configuration_file))
>> +			return;
> 
> If the file exists but can't be loaded, should we make it a fatal error
> ? Continuing by ignoring malformed configuration files means we'll run
> with a configuration different from what the user expects.
> 
>> +	}
>> +
>> +	for (const auto &path : globalConfigurationFiles)
>> +		if (loadFile(path))
>> +			return;
> 
> Please use curly braces for the outer scope.
> 
>> +}
>> +
>> +GlobalConfiguration::Configuration GlobalConfiguration::get() const
>> +{
>> +	return *yamlConfiguration;
> 
> I think you can drop this private function and access yamlConfiguration_
> directly internally.
> 
>> +}
>> +
>> +/**
>> + * \brief Initialize the global configuration
>> + */
>> +GlobalConfiguration::GlobalConfiguration()
>> +{
>> +	load();
>> +}
>> +
>> +/**
>> + * \typedef GlobalConfiguration::Configuration
>> + * \brief Type representing global libcamera configuration
>> + *
>> + * All code outside GlobalConfiguration must use this type declaration and not
>> + * the underlying type.
> 
> What's the reason for that ?
> 
>> + */
>> +
>> +/**
>> + * \brief Return configuration version
>> + *
>> + * The version is (optionally) declared in the configuration file in the
>> + * top-level section `version', alongside `configuration'. This has currently no
>> + * real use but may be needed in future if configuration incompatibilities
>> + * occur.
>> + *
>> + * \return Configuration version as declared in the configuration file or 0 if
>> + * no version is declared there
>> + */
>> +unsigned int GlobalConfiguration::version() const
>> +{
>> +	return get()["version"].get<unsigned int>().value_or(0);
>> +}
>> +
>> +/**
>> + * \brief Return libcamera global configuration
>> + *
>> + * This returns the whole configuration stored in the top-level section
>> + * `configuration' of the YAML configuration file.
>> + *
>> + * The requested part of the configuration can be accessed using \a YamlObject
>> + * methods.
>> + *
>> + * \note \a YamlObject type itself shouldn't be used in type declarations to
>> + * avoid trouble if we decide to change the underlying data objects in future.
>> + *
>> + * \return The whole configuration section
>> + */
>> +GlobalConfiguration::Configuration GlobalConfiguration::configuration() const
>> +{
>> +	return get()["configuration"];
>> +}
>> +
>> +} /* namespace libcamera */
>> diff --git a/src/libcamera/base/meson.build b/src/libcamera/base/meson.build
>> index 94843eb95..4c0032845 100644
>> --- a/src/libcamera/base/meson.build
>> +++ b/src/libcamera/base/meson.build
>> @@ -16,6 +16,7 @@ libcamera_base_internal_sources = files([
>>       'event_dispatcher_poll.cpp',
>>       'event_notifier.cpp',
>>       'file.cpp',
>> +    'global_configuration.cpp',
>>       'log.cpp',
>>       'memfd.cpp',
>>       'message.cpp',
>