This happens even though the user-level configuration is correctly set up under ~/.config/input-remapper-2/ and autoloading works as expected via input-remapper-control --command autoload.

This behavior appears to originate in how the daemon resolves the path to its configuration. Although the logic is split across modules, the effective path is built by global_config.py using:

self.path = os.path.join(PathUtils.config_path(), "config.json")

PathUtils.config_path() returns a directory based on the user's home directory—likely via os.path.expanduser("~") or $HOME—which evaluates to /root when the service is run as root. As a result, the daemon attempts to read /root/.config/input-remapper-2/config.json, even though in typical setups the configuration exists only under the invoking user's home directory (e.g. /home/jdoe/.config/...).

Why this may be misleading

• The service runs as root, and looks for a configuration in /root/.config/..., which is typically nonexistent.
• This results in an error that suggests something is broken, even though the tool is functioning correctly.
• In most desktop use cases, remapping is configured per-user, and there's no expectation of a config under /root.
• It clutters logs and leads to confusion, especially for users who have configured everything correctly using the GTK frontend.

Hypothetical improvements

• If the service runs as root and no /root/.config/input-remapper-2/config.json is found, it might make sense to treat that as an expected case, not an error.
• The config path could be made configurable via an environment variable (e.g. XDG_CONFIG_HOME) or a command-line option.
• If such cases are not blocking functionality, logging a warning or info message instead of an error might avoid confusion.

Polkit integration note

The package installs a polkit policy (/usr/share/polkit-1/actions/input-remapper.policy) that defines a single action inputremapper, annotated for the binary /usr/bin/input-remapper-control.

This means that when launching the actual service (/usr/bin/input-remapper-service) via pkexec, no matching polkit action applies, which may result in inconsistent behavior: password prompts, lack of elevation, or ignored privilege rules.

It might be useful to:

• Provide a dedicated polkit action for input-remapper-service.
• Clarify in the documentation how the daemon is expected to be launched in user sessions.

System details

• OS: Fedora 42
• Package: input-remapper 2.1.1-2.fc42.noarch
• Setup: Single-user graphical session. User-level remapping via GTK GUI and config under ~/.config/input-remapper-2/. Polkit used to launch the daemon with pkexec.

Thanks for maintaining this useful project.