[PATCH xinit v2 3/3] startx: Under Linux start X on the current VT

[Mark Kettenis]

> From: Hans de Goede <hdegoede at redhat.com>
> 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?