Feature Request: Toggle profiles when using the equal hardware fingerprints

[CDanU]

Here is my setup: I have a monitor connected to my laptop. Most of the time I only use the connected monitor and let the laptop screen turned off.
Sometimes I need to have them both working, so i made profiles for each situation: One with the laptop screen being off and one with it being on, while allays having the monitor connected and used.
Unfortunately in this situation autorandr uses always only one of the profiles and does not toggle them if it detects multiple profiles with the same hardware fingerprints.

[phillipberndt]

autorandr sorts the profiles by modification date and uses the first one that matches, and updates a profile's mtime when it loads it. So the behaviour is intentionally (see #16) exactly the inverse of your use case. The rationale for this is that if autorandr is set up to automatically run (e.g. after boot, after waking from s3) it will then likely load the profile that the user wants.

To work around this in your case, you could add a block script to both profiles (Just put an executable file into the profiles' directories) that blocks the profile (by returning with a zero exit code) if it is already loaded. Manual loading will still be possible, but automated detection will skip the profile.

[CDanU]

Thanks for the reply. I will use the described workaround, so this request can be closed.

E: I tried your suggestion and found a little problem. How does one get the information which profile is currently used? I tried to grep the output from 'autorandr --dry-run' but the problem is that it is also executing the block script and therefore causes a infinite loop.

I guess I have to put some logic into a postscript unless you have another tip for me.

[phillipberndt]

I thought that this might be a problem. How about passing some parameters to the block script? For your use case, the name of the old profile (if applicable) would suffice. I am not sure yet if any further passed information would be useful..

[CDanU]

Well for my use case I would need the current profile name and from that need to be able to predict the next profile name. While 'autorandr --dry-run' did not work it gave me a list from which I could select the name of the profile which came after the current profile.

p1 (detected) (current)
p2 (detected)
p3 (detected)

Still there would be the problem if one does use more than two profiles in this example the profile names would change positions when loaded.

I guess the most simplistic implementation for this would be to add a new --toggle switch which gets a list of non blocked matching profiles, sorts them alphabetically by name and activates the profile that comes after the current active profile.

[phillipberndt]

You should be able work around that as well, by blocking a profile based on whether you'd want autorandr to switch to it or not. e.g. if you want the order p1 -> p2 -> p3, you could give p2 a block script that blocks the profile unless p1 is loaded, one to p3 that blocks unless p2 is loaded, and one to p1 that blocks if either p1 or p2 are loaded. (This way, p1 will be loaded if p3 or none of the profiles was active.)

This would still require a patch to autorandr to pass the name of the old profile to the block script.

Do I miss anything here or would this work?

[CDanU]

Indeed this is a good solution, while I don't really need any specific profile order it is still nice to have the possibility to set up one.
I don't see any further problems.

[phillipberndt]

autorandr now passes the environment variable $AUTORANDR_CURRENT_PROFILE to the block script.

[CDanU]

Thx, everything works as expected.