[Feature Request] Tiered config default configuration files

[toastal]

Short Description

Current user UX story: I am a user on a system without root access. My admin has set some default settings, but I need a way to change these for my needs. 1. I don’t have access to the root files & am not savvy enough to be tweaking systemd files to set the configuration. I am however just savvy enough to be told where I need to write a file to knowing that the driver will use my configuration as many of my applications put their text-based configuration files in my $XDG_CONFIG_HOME already.

Proposed solution: Have /etc/asus-dialpad-driver for the administrator defaults as well as read from $XDG_CONFIG_HOME/asus-dialpad-driver (~/.config/asus-dialpad-driver for odd systems not supporting XDG). The application then merges configurations. …I would say this is a pretty common pattern anyhow.

Open question: what is the behavior of passing in the configuration as an argument? Does it override everything? Become the fallback?

New dependencies

Something make XDG a cinch with fallbacks, probably OS agnostic

Additional Info

For NixOS this would be great since now we can declaratively describe the setup as an INI file for etc & then home-manager / pick-your-tool can extend for users wanting declaritive home config… & would simplify the module. Anyone with ambition could easily write a configuration GUI as well for the user-level configuration file if they really wanted.

[toastal]

I also could very much be misunderstanding something since I haven’t quite gotten it working on NixOS yet 😅. I might be that we are already writing a config file to a directory, but that doesn’t mean there still isn’t room for system-level config.

[ldrahnik]

About dialpad_dev: Currently, the driver also writes back to the config, for example option enabled and current/latest brightness. But not only that. Then it should be written to which config? User config? But which user config if they were enabled in two places? Cancel this behavior completely? I see the fact that it is possible to find out from the terminal from the config whether NumberPad/DialPad is activated as a positive thing. One of the reasons why it was designed this way was a kind of preview of how a kernel driver could be designed where the current brightness, enabled, and more are also displayed and controllable in a similar way via virtual control files.

Question: What would be a proper way to pre-set up for example brightness of a laptop keyboard as a admin for all users using kernel module control files?

About layout files e.g. proartp16.py (python files because of from libevdev import EV_KEY, EV_REL): Read-only file from the driver point of view.

[ldrahnik]

Open question: what is the behavior of passing in the configuration as an argument? Does it override everything? Become the fallback?

ExecStart=$INSTALL_DIR_PATH/.env/bin/python3 $INSTALL_DIR_PATH/dialpad.py $LAYOUT_NAME $CONFIG_FILE_DIR_PATH

$CONFIG_FILE_DIR_PATH currently it tries to load the config file under the given dir path, the name of the config file is hard-coded dialpad_dev. If the config file exists already when the driver starts, found options are used and inside the driver merged with the defaults of the not found options, then it is written back to the config file. The config file is watched by the driver and any change is almost immediatelly used. So is possible to activate NumberPad via config using enabled option.

[ldrahnik]

@toastal What about / Would solve the problem adding support for file in second argument containing (where is now supported only directory for config file):

root/direktory/
user/directory/

It would search config files (on each line) and read them in these dirs in this order and to the directory on the last line also write back.

[toastal]

I haven’t seen something like this before, but it could work… a change like this could then enable that Nix config to be referenced but still overridden (Nix doesn’t use/need FHS—just a pile of symlinks from the store).

The pattern I still see most often tho is FHS + XDG styles /etc/my-app/cfg.ini + ${XDG_CONFIG_HOME:-$HOME/.config}/my-app/cfg.ini to allow system-level defaults with user-level overrides… clearly defines ownership/hierarchy. I think like OpenSSH, PipeWire, mpd, systemd, & so on.