Xorg is not started on first free tty (tty1)

[GoTeamAnt]

Xorg is started on tty2:

$ ps ax | grep Xorg
    600 tty2     Ssl+   4:25 /usr/lib/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /var/run/sddm/{5a3bbd6d-1d5e-4fbf-8438-e5c609fac15f} -noreset -displayfd 17

I am running sddm 0.19.0 on Archlinux which has a patch for allocating vts.
https://github.com/sddm/sddm/commit/f0b6dec6.patch

tty1 is free:

$ sudo fuser /dev/tty1
$ sudo fuser /dev/tty2
/dev/tty2:             600

Expected:

Xorg should be started at tty1.

[wenzezlaus]

I have the same issue.
Arch linux 5.11.15, sddm 0.19.0
X starts on tty2 although tty1 is free. Setting MinimumVT=1 in sddm.conf yields no effect.

[tpgxyz]

Sounds like downstream issue. Please file a bug report for your distribution.

MinimumVT has been removed because of f0b6dec6 same as first free VT discovery

[wenzezlaus]

The bug report to Arch Linux was closed as upstream related.
https://bugs.archlinux.org/task/70544
https://bugs.archlinux.org/task/70528

[GoTeamAnt]

I think the code to determine a free vt has to take the own (active) vt into account as well.

Here is the output from a small program which basically runs the same code (VT_GETSTATE and VT_OPENQRY ioctl) as sddm and outputs it:

The program was started at vt3 and there was another getty session on vt2, sddm was not running.

start at vt3
VT = 1 VT-STATE active 3 state 0x004d
vt1 is reported as free, we are currently on vt3
switch to vt1
VT = 4 VT-STATE active 1 state 0x004f
This is the problem, just by looking at vt1 tty1 is reported as occupied (no process has tty1 open).
Personally, I think this is a kernel bug but what do I know. There is also no login, systemd/getty seems to be affected too.
switch to vt2
VT = 1 VT-STATE active 2 state 0x004d
back to vt3
VT = 1 VT-STATE active 3 state 0x004d

Currently only the next free vt is taken into account, which is 2 if 1 is currently active.

I think the code should look like this (find lowest vt):

// after ioctl calls
nextFreeVT = vt;
if (vtState.active < vt)
{
   nextFreeVT = vtState.active;
// an additional check if the active tty is used by a process might be warrented,
// or just make an exception for vt1
}

[GoTeamAnt]

The offending patch was reverted in Archlinux.

But the problem still lingers around for the upcoming 0.20.0 release.

Related: #1398

[grahamperrin]

Expected

I'm accustomed to things at ttyv8 but that's probably because I'm on FreeBSD.

% grep -v \# /etc/ttys | slowcat --bps 600
console none                            unknown off secure
ttyv0   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv1   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv2   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv3   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv4   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv5   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv6   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv7   "/usr/libexec/getty Pc"         xterm   onifexists secure
ttyv8   "/usr/local/bin/xdm -nodaemon"  xterm   off secure
ttyu0   "/usr/libexec/getty 3wire"      vt100   onifconsole secure
ttyu1   "/usr/libexec/getty 3wire"      vt100   onifconsole secure
ttyu2   "/usr/libexec/getty 3wire"      vt100   onifconsole secure
ttyu3   "/usr/libexec/getty 3wire"      vt100   onifconsole secure
dcons   "/usr/libexec/getty std.9600"   vt100   off secure
% grep -C 1 Virtual\ terminals /etc/ttys
ttyv0   "/usr/libexec/getty Pc"         xterm   onifexists secure
# Virtual terminals
ttyv1   "/usr/libexec/getty Pc"         xterm   onifexists secure
% uname -KrsU
FreeBSD 14.0-CURRENT 1400021 1400021
%