Feat: autorandr fails during boot when people installing packages don't read github instructions - FIX INCLUDED

[Alexander-Weinhart]

Summary

Autorandr repeatedly failed because the default profile was missing. It's been doing this since autorandr was installed because I attend the special adult learning center, which doesn't teach how to read README instructions.
This would be a me-problem, but these failures would go unnoticed during boot without checking logs, this would be common for users who don't read github readmes for package-manager packages.
Not creating a default profile broke autostart/display-switch flows that rely on default fallback behavior.

Evidence from logs

From boot logs on 2026-02-20:

• Feb 20 08:11:37 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)
• Feb 20 08:17:57 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)
• Feb 20 09:14:32 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)
• Feb 20 10:50:20 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)
• Feb 20 11:01:24 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)
• Feb 20 11:20:56 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)
• Feb 20 11:39:45 ... autorandr[...] Failed to load profile 'default': Profile not found (line 1637)

These were accompanied by service/autostart failures like:

• app-autorandr@autostart.service: Failed with result 'exit-code'
• app-autorandr-kde@autostart.service: Failed with result 'exit-code'

so the service itself would exit and it wouldn't be active during boot. I'm sure you're aware.

Root cause

default was not guaranteed to exist before code paths attempted to load it. This is due to a possibility of a lack of reading comprehension from the user while reading the instructions. A regular package install would be ready to go after the install, I'd like that to be true for autorandr.

Fix implemented

When saving any non-default profile, I fixed autorandr locally to check if default exist. If not, it sets it up. This pads corners due to users like me not reading the instructions. During setup, a user is able to select one preferred always-connected default monitor, such as a laptop monitor or any permanent monitor. The new setup process works, so with permissions, I can create a pull request with it if you'd like.

Result of these errors and result of root cause

• autorandr repeatedly failed with: "Failed to load profile 'default': Profile not found".
• systemd kept restarting autorandr until it hit rate limits ("start-limit-hit"), then stopped trying.
• user autostart units for autorandr failed, so display profile switching did not complete at session startup.
• fallback behavior based on "--default default" could not run, leaving display layout in an unmanaged or inconsistent state.
• repeated retries created log spam and extra startup churn.