Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't Load profile if process already running #4

Open
Bass-03 opened this issue Mar 12, 2020 · 7 comments
Open

Can't Load profile if process already running #4

Bass-03 opened this issue Mar 12, 2020 · 7 comments

Comments

@Bass-03
Copy link
Contributor

Bass-03 commented Mar 12, 2020

Because of this:

self._prevent_duplicate_running()

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?

@rliou92
Copy link
Owner

rliou92 commented Mar 29, 2020

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?

@Bass-03
Copy link
Contributor Author

Bass-03 commented Mar 30, 2020

@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:

  • figure out if the process is live and/or daemonized
  • if process exist:
    • kill the process existing
    • start a new one, daemonized
  • else: Do same thing as --autoload

What do you think?

@rliou92
Copy link
Owner

rliou92 commented Dec 6, 2020

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?

@Bass-03
Copy link
Contributor Author

Bass-03 commented Dec 7, 2020

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.

@rliou92
Copy link
Owner

rliou92 commented Dec 7, 2020

Ok. Monitor setup detection is pretty tricky.

@Bass-03
Copy link
Contributor Author

Bass-03 commented Dec 7, 2020

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

@rliou92
Copy link
Owner

rliou92 commented Dec 11, 2021

I implemented this if you still need it. Not sure how the program responds in practical situations, but the functionality is there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants