-
Notifications
You must be signed in to change notification settings - Fork 37
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
Feature Request: Auto detect previously used display and apply last setting #21
Comments
Hi @AdamSLevy,
It seems to be linked with #20. Initially, @pkhamutou had set his two monitors via a specific xrandr command but after running mons, he got an unexpected display. Indeed, mons turns off monitors and resets display in certain cases with Right. I've been investigating for few days on xrandr options but none have turned up yet.
Priority: keeping mons as simplest as possible. To be honest, I feel like let's make out the tip of the iceberg to finally decide. |
Thanks for the reply.
I understand and appreciate wanting to keep mons as simple as possible.
Instead of a configuration file, how do you feel about parsing the -e
option along with the -a option. This would then daemonize mons and look
for an added display to extend and run the -o option when a display is
removed.
I suppose this could be implemented with a systemd service or udev rules
calling mons. That might be something to package with mons in /usr/share
Just brainstorming as this is something I have wanted to automate for
myself.
…On Thu, Jan 11, 2018, 1:20 PM Thomas Venriès ***@***.***> wrote:
Hi @AdamSLevy <https://github.com/adamslevy>,
Thanks for the feedback and future contributions perhaps.
set the display to some pre configured state, from either ... just by
remembering how the user had it set previously.
It seems to be linked with #20 <#20>.
Initially, @pkhamutou <https://github.com/pkhamutou> had set his two
monitors via a specific *xrandr* command but after running *mons*, he got
an unexpected display. Indeed, *mons* turns off monitors and resets
display in certain cases with xrandr --auto that definitely breaks the
previous very-specific settings (but of course, not the simplest ones).
Right. Last week, I've been investigating for few days on *xrandr*
options but none have turned up yet.
from either a configuration file
Priority: keeping *mons* as simplest as possible.
Assigning a *rc* file to *mons* sounds like a risky bet.
Leveraging the Xorg /etc/X11/xorg.conf.d/*.conf configuration files or
X11 existing features as post-detection hook could help.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AF2XcKwQCqIYMfui6WYZmSAjSWTJFPgvks5tJokogaJpZM4RYths>
.
|
EDIT: Why not ?
|
I'm just commenting to share a script that I wrote to solve this issue for my specific use case. I have a udev rule that detects changes to my specific monitor and then calls this script. When two displays are detected, and it is not already in extend mode, it extends the display and moves all of my i3 windows over to the new display. I doubt much of this will be useful to you for use in mons but it might give others who come here searching for a solution an idea of how they can solve it themselves. Thanks again for your awesome minimalist software! I am using mons, xpub, batify, and pug! My script, called by my udev rule on display change:
|
Thanks @AdamSLevy for contribution. |
I use Mons on my laptop on a daily basis. I love the simplicity but I wish there was a way that it could be totally automated. I would appreciate if the
-a
option which daemonizes the process would also detect when a monitor was plugged in and set the display to some pre configured state, from either a configuration file or just by remembering how the user had it set previously.I'm going to start perusing your code and see if there is a simple way for me to add this feature and submit a pull request. Let me know if this is something you feel fits your project and if so please suggest how you think this should be implemented.
Thank you!
The text was updated successfully, but these errors were encountered: