-
Notifications
You must be signed in to change notification settings - Fork 122
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
/etc/pm/sleep.d/40autorandr does not work with startx/xinit sessions #39
Comments
Does |
..did yesterday's commit fix the issue? |
No,
I think the problem is "just" that there's no display manager that would update the |
I have searched for portable ways to find which user "owns" an X11 session, but haven't been able to find one.. I doubt that this is generally solvable (at least, without creating potential security issues like one might do by e.g. searching for any program that is connected to the display and then su to its owner.). |
Yeah. |
This seems to be the best course of action, though I'm still not perfectly happy with su'ing to some user based on the output of some command that said user can influence. See the latest change. |
FWIW, here's some adhoc method, which might be too specific, but works for me:
|
That'll find any X11 session, not specifically yours, right? But in |
Another thought, do you think this would work?
(I'm aware that dash does not support the array syntax, this is currently written for bash) |
Works for me. This does the same, using
|
Great. I'll include this as a fallback, then. (Your variant doesn't do exactly the same; actually, checking that there isn't another user logged in was an intentional security measure.) |
Hmm. Isn't the idea/point to handle all logged in users? |
Sure. That works, too, if the utmp database is used correctly. If it isn't, we still lack a reliable way to determine the owner of an X11-session. We use the information to btw, here's an awk only variant of my above approach:
|
I committed the workaround; closing this for now, though I'd still prefer to have a proper fix. |
Bumping an old one, but I did face this issue though I use SDDM. It looks like utmp is not updated, so my active login is not reflected by w/who. I've addressed this by using loginctl:
|
It'd be an option to detect whether loginctl is available and use it preferably if it is. Does this DISPLAY detection script work for you? That is, does
output the correct display? The SO answer however claims that this won't work with gdm. Here's another alternative: We could search for all processes that locally run and have access to the display and check whether except for root, there's only one owning user:
does this work for you? |
Yes, those work for me. I prefer the loginctl based approach though. Going through all the processes seems heavy -- we can perhaps use loginctl and consider other options for GDM? |
So do I. I wondered whether this works because we need some fail-safe in case all other detection methods fail. That was what the final |
Yes, I think that makes sense. I suppose a few |
I tried implementing this. Could you test if the version from the new branch works for you, please? |
This works for me with the change I mentioned in your commit. Thanks for fixing this! |
When using
startx
/~/.xinitrc
to start X, the display detection in/etc/pm/sleep.d/40autorandr
fails:The output from
who
looks like this:The text was updated successfully, but these errors were encountered: