Bug#760916: brltty interferes with getty autostart

[Samuel Thibault]

Michael Biebl, le Fri 12 Dec 2014 18:13:33 +0100, a écrit :
> - it keeps /dev/tty0 open to be able to synthesize keypresses with
>   ioctl(TIOCSTI) for instance,

I believe this is where things are going wrong. Cc-ing brltty's
upstream, Dave Mielke.

Dave, the issue at stake is that systemd normally auto-starts getty
on-demand on the various VTs, and when brltty is running, that doesn't
work any more.

What systemd notably does when trying to auto-start a getty is the
following:

        fd = open_terminal("/dev/tty1", O_RDWR|O_NOCTTY|O_CLOEXEC);
        if (fd < 0)
                return -errno;

        if (ioctl(fd, VT_GETSTATE, &vt_stat) < 0)
                r = -errno;
        else
                r = !!(vt_stat.v_state & (1 << vtnr));

In the kernel, VT_GETSTATE sets bits in vt_stat whenever at least one
process has the tty opened.  What I believe happens is the following:

- bootup, on VT1, getty starts on VT1
- switch to VT2
- brltty quickly reopens /dev/tty0, in order to be able to synthesize
keypresses there.
- systemd-logind not so quickly tries to auto-start a getty on VT2,
but before that, checks that nobody is using it with the abovepasted
VT_GETSTATE.  This tells systemd-logind that somebody is using it,
brltty, and thus aborts auto-starting the getty.

As usual with bugs, both parties are "right" in what they are doing, and
it's the combination of both point of views which produce a bug.

AIUI, it is quite out of question that brltty delays reopening /dev/tty0
on VT switch, since brltty users do often switch from one VT to the
other etc.

Could you see together how to deal with this issue?  This will really be
painful for all brltty users on all linux systems switched to systemd.

Samuel