Open Bass-03 opened 4 years ago
If you manually load a profile, the existing running process will detect a screen change and change the screen according to your profile afterwards, overriding the manual load. Is this what you wanted to happen?
@rliou92 that is the thing, it happened a couple of times the running process did not detect the setup, I had to trigger it manually.
My solution was to kill it and start it again, but umonitor -l profile
should force the given profile without needing to kill the process, IMO
Or maybe add a new option to reload the whole thing for such cases, for instance umonitor -r
which would:
What do you think?
Yes, I like both ideas!
Though the root cause of the problem is that the running process failed to detect a change in setup. Are you able to reproduce such a scenario?
towards the root cause, I think it might be my hardware, I am currently using autorandr (don't remember why I switched), and I have some issues, I am going to remove it to give umonitor a try again.
I'll come back wen I see issues.
Ok. Monitor setup detection is pretty tricky.
It is, that is why I am suggesting some workarounds in case sometimes it just doesn't work :) Just now I was fighting with my monitors, I use a dock station from work that it is said to be troublesome .. so sometimes it just doesn't cooperate
I implemented this if you still need it. Not sure how the program responds in practical situations, but the functionality is there.
Because of this: https://github.com/rliou92/python-umonitor/blob/6175f3f962c4b9b90692c61bf4f033b0674b9b42/umonitor/umonitor.py#L119
Can't load a profile when the process is already running, which is kind of annoying.
I had to delete my "laptop" profile (no external screens) because the thing kept turning off screens when I disconnected the HDMI cable, and I could not load it manually while I was debugging.
Is there a reason for this?