Mir configuration system

[wmww]

I think it would be useful to have a sort of meta-issue for configuration. Configuration is a big problem we haven't put enough thought into. Rather than a patchwork of inconsistent solutions, I propose we think of all Mir configuration as a single problem. Our solution would cover:

• Display configuration (already somewhat addressed by the .display .yaml files, would probably need to keep those for backwards compat)
• Input configuration (keymap, key repeat, pointer accel, scroll direction, etc.) This is important both to suit user's preferences and accessibility
• Default startup applications? Perhaps out of scope.
• Other?

Ideally there would be multiple ways to change the configuration, and they would be compatible with each other:

• If no other configuration information is present, Mir should use sensible defaults
• There should be standard config file(s) that affect all Mir servers on the system
• Individual servers/desktops should be able to have their own Mir configuration files parsed by the same mechanism as the standard one. Properties set here should override the generic config.
• Wayland protocols such as wlr-output-management-unstable-v1 should allow clients to configure Mir. These could be enabled or disabled by servers like any other Wayland protocol. Servers should be able to choose if to accept or reject changes made this way.
• Servers should be able to change configuration programmatically. This allows them to implement 3rd party configuration protocols, their own config file format, integration with a database, etc.

Open questions:

• File format of the default config files? YAML is obvious because it's decent and we've already got the library. TOML or something else might be easier for some users to understand.
• Single file or multiple files? Perhaps we keep display configuration as-is and add a separate input configuration file?
• Do we want to make configuration part of the Miral ABI, or have some sort of dynamic interface?
• Should changes made by clients be propagated into generated config files so they're persistent? Should Mir support some sort of configuration database? Or leave persistent changes up to servers?
• Should Mir support hot-reloading config files? What about accepting config changes made by servers on-the-fly?

Please leave thoughts, concerns and suggestions below. AFAIK there's no timeline for when this will actually get done.

[AlanGriffiths]

We already have a configuration system (based on Boost.Program_options) that supports:

1. Commandline options
2. Environment variables
3. A configuration file

Comparing to your checklist:

• If no other configuration information is present, Mir should uses sensible defaults 👍
• There is no "standard config file(s)" that affect all Mir servers on the system 👎 (But I don't think this would be hard to add)
• Individual servers/desktops have their own Mir configuration files 👍
• This doesn't contain the same options as those controlled by Wayland protocols such as wlr-output-management-unstable-v1.
• There's no facility for Servers should be able to change configuration programmatically 👎

And your "open questions":

• File format of the default config files? Key=value pairs is widely understood 👍
• Single file or multiple files? We have mutiple files now (.config and .display)
• Do we want to make configuration part of the Miral ABI, or have some sort of dynamic interface? Configuration (using the mis-named CommandlineOption class) is part of the MirAL ABI 👍
• Should changes made by clients be propagated into generated config files so they're persistent? Should Mir support some sort of configuration database? Or leave persistent changes up to servers? The mirserver API allowed Lomiri to save display configururation changes, that seems sensible.
• Should Mir support hot-reloading config files? What about accepting config changes made by servers on-the-fly? Many configuration options (e.g. the console provider) are not suitable to change in a running server.

I think we already address a lot of your concerns.

[wmww]

I guess the specific problem I'm trying to solve is dynamic configuration. The most immediate problem is that there is no input configuration system. The .display config files are for a specific purpose and it now seems extending them might not be the best option for the general case.

When I come back to working on this problem, I might try to add a generic Mir config YAML file. This would be designed to be applicable to all Mir compositors and have overrides in compositor-specific config files. It would also be designed to be hot-reloaded. It would not replace the .display files (most normal desktop compositors wouldn't use a .display) nor the boost options system (that's for startup configuration that doesn't change). It would start with just input, but could be extended for whatever else we needed.

This is somewhat on the back burner. There's a number of things more important at the moment.