> From: Hans de Goede <[email protected]> > Date: Thu, 27 Mar 2014 12:55:57 +0100 > > When we let X allocate a new VT, systemd-logind will not recognize any > processes running on this VT as belonging to a valid session (since there > was no pam session opened on that tty). > > This causes problems like PolicyKit denials for these processes. > > ConsoleKit under Linux has been deprecated for a few years now and is no > longer being maintained, so simply make this the default under Linux.
What you're basically saying is that on a modern Linux systems, the historic behaviour where X allocates a new VT and occupies it is no longer wanted. This raises several questions: 1. Is there consensus among the various Linux distros that this really is the desired default behaviour? 2. Doesn't this really mean that the default behaviour of the X server itself should be change to take over the VT it is running on instead of allocating a new one? An excellent opportunity to remove code instead of adding more hacks I'd say ;). > Note we do not pass in the vt if the user has specified an alternative server > to start, as the vtX argument is only valid for the Xorg server, likewise we > omit it if the user has specified any other server arguments. If I read the shell code correctly you're also not passing the vtX argument if the user specifies any arguments to be used with the standard server. For example, startx -- -depth 16 will not pass the necessary vtX argument. Also: > --- > startx.cpp | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/startx.cpp b/startx.cpp > index b7a29f9..8426734 100644 > --- a/startx.cpp > +++ b/startx.cpp > @@ -187,6 +187,16 @@ XCOMM process server arguments > if [ x"$server" = x ]; then > server=$defaultserver > > +#ifdef __linux__ > + XCOMM When starting the defaultserver start X on the current tty to avoid > + XCOMM the startx session being seen as inactive: RHBZ#820675 This sort of vendor-specific bug references isn't very helpful is it? _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
