[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Xorg replaces TTY1



On 11/22/2015 02:56 PM, The Wanderer wrote:
On 2015-11-22 at 15:24, Brian wrote:

On Sun 22 Nov 2015 at 14:12:09 -0500, The Wanderer wrote:

On 2015-11-22 at 13:26, Brian wrote:
   * 10-startx-Under-Linux-start-X-on-the-current-VT.patch,
     11-startx-Pass-vtX-as-long-as-the-user-did-not-specify-.patch: By default
     start the server on the current VT, this is necessary to avoid logind to
     see the startx session as inactive (Closes: #743015 LP: #1247484)
In other words, it's a consequence of logind, which is part of the
systemd suite and is shipped in the systemd package.

So yes, this change does have to do with systemd - just not with
the binary named systemd, or with the init system which is
(theoretically) contained within that binary.
It looks like it is. What functional disadvantage is it to a user of
sysvinit or systemd? Starting X on vt7 is not a Law of Nature.
The loss of the ability to switch to the VT from which I started X, and
either see the most recent X console output there or (more importantly)
kill X semi-cleanly via Ctrl-C.

I have needed the latter on multiple occasions, including I think at
least one where logging in to another VT would not have been a viable
option (though I forget why, and it's possible that I'm wrong about
that). I think that's enough to count as a functional disadvantage.

Not to mention, "functional disadvantage" is not the only valid grounds
on which to object to a change... but if we try to get into that very
deeply, we'll be at risk of flamewar, of reviving the systemd flap again
(we're already skirting the edges of it), and of getting offtopic. (In
order of increasing likelihood.)

AFAIK I've yet to restart X since the xinit version in question hit
my system, but if I'm now going to be affected by this behavior
despite not having logind even installed on this machine, I will be
- once more - at least mildly irritated. I don't even see any
indication (in 'man startx', which is the obvious appropriate
place) of how to disable this behavior, either on the startx
command line (which would be unacceptable anyway) or in a config
file...

(Digging a bit finds what is probably the appropriate command-line
option in 'man Xorg', but still no obvious indication of where to
set it in a config file, given that I have no xorg.conf and
creating one seems undesirable for other reasons.)
If the OP (or anyone else) wants X on vt7:

startx -- vt7
That requires specifying it by hand every time startx is run. As I
indicated, that is unacceptable; I don't have to specify the VT manually
every time I lanch X now in order to get the current behavior, and I
shouldn't have to specify it manually at every launch in order get that
behavior after a change of the default.

Where/how would it be possible to specify this in a config file, so that
it can be set-and-forget if desired?

(Leaving aside the fact that setting it explicitly in a config file
wouldn't replicate current behavior in the scenario where multiple
instances of X are launched on the same machine; I've had X open on vt7
and vt8 at the same time, previously, with no manual VT specifying
involved. That's something I do rarely enough that it won't affect me
personally, however; it's just something whose loss I'd find annoying in
principle.)

My box always has three X sessions going at the same time (still on Wheezy). I use an alias to set the vt. The value of the alias is determined by who is logged on and running startx:

for me:
    alias startx='clear; startx -- :0 vt07'

for my wife:
    alias startx='clear; startx -- :1 vt08'

for my daughter:
    alias startx='clear; startx -- :2 vt09'

I sincerely hope that, if and when I update to Jessie, this behavior will still be available as this allows any one of us to sit down at the computer and with a fixed keystroke combination get to our own X session, while not requiring that we logon to a fixed console.





Reply to: