[Feature Request] Ability to cycle between multiple default profiles

[9las]

I would like to request a feature enhancement for autorandr that enables users to cycle through multiple default profiles when no matching profile is detected.

Currently, autorandr requires users to set up profiles for each specific display configuration. This setup allows autorandr to detect the hardware configuration and cycle between the corresponding profiles. However, this can be cumbersome, especially for users who frequently encounter unrecognized hardware setups. Often, I find it more convenient to cycle through a predefined set of profiles that remain consistent regardless of the specific hardware configuration. Adding the ability to cycle between multiple default profiles would address this need.

The proposed feature would allow users to define and rotate through a set of fallback "default profiles." These profiles would only activate when no regular profile matches the current hardware setup. If a matching regular profile is detected, the fallback profiles would be excluded from the rotation, maintaining the current behavior for normal profiles. Furthermore, it should be possible to configure these default profiles with virtual configurations so that they will work no matter e.g. the resolution of the connected monitors.

While the current wildcard EDID matching offers some flexibility for creating general profiles, it comes with significant limitations:

1. Wildcard EDID matching only allows generalization based on EDIDs, not on connected output names.
2. Profiles using wildcard EDID matching cannot function as fallback profiles—they are included in the regular profile rotation, which may not align with user preferences.
3. The static nature of configuration files makes it difficult to create general profiles suitable for monitors with differing resolutions or specifications.

Implementation Suggestions

The simplest way to implement the feature would probably be to allow the --default option to take multiple profile names, say deafult1, default2, default3 and then symlink deafult1, default2, default3 to different virtual configurations.

Alternatively, the feature could be implemented by:

1. Extending wildcard matching to support connected output names (e.g., a single * in the setup file matches any configuration).
2. Add metadata in the setup file to indicate that a profile functions as a fallback.
3. Allow config files to point at one of the virtual profiles.