dev/auto-args #3
Conversation
This allows for logind to detect that X is part of the current user's session. Without this, things such as PolKit do not track that the user is actually on the session. See https://bugzilla.redhat.com/show_bug.cgi?id=806491 for more information.
This allows commands such as "systemctl --user start xorg@:1.service" to start an xorg instance with DISPLAY=:1.
|
Hey, great patches! One question I have though about patch "Make xorg.service an instanced service … 22e7018 ", I think this directly breaks user-session-units unless we figure out a way how to address the case where user sessions are initiated manually at startup. The rest of the patches actually look really good so I hope we can work something out here and get it merged. |
|
There should probably be a xorg@.service for manual startup as well as xorg.service for "give me something that works" case which omits the display argument all together. I don't know when DISPLAY gets set; I would have though that X set it, not startx, but maybe. What I've tried so far for systemd --user has not been sufficient (it's close, but not quite there yet), so I'm back to startx for a bit. I'll see if I can get another stab at it next week (unlikely to happen before then). |
| @@ -17,7 +17,10 @@ Before=xorg.target | |||
|
|
|||
| [Service] | |||
| Type=notify | |||
| ExecStart=@prefix@/bin/xorg-launch-helper :0 -nolisten tcp -noreset vt1 | |||
| StandardInput=tty-force | |||
There was a problem hiding this comment.
This doesn't seem as forceful as it would indicate. Maybe something with --user being denied access? Upstream bug?
startx is able to determine a default for the display and vt. Since this is pretty much a replacement for systemd setups, it should be able to figure it out as well.
One known issue is that it seems as if the vt cannot be taken over properly for some reason (I'm unsure of how startx is able to take it over, so maybe some extra magic is necessary).