Bug#760916: brltty interferes with getty autostart

[Samuel Thibault]

Dave Mielke, le Tue 20 Jan 2015 00:34:27 -0500, a écrit :
> [quoted lines by Samuel Thibault on 2014/12/29 at 18:30 +0100]
> >> We could open it on demand rather than immediately?
> >
> >On which demand?
> 
> Brltty could delay opening the tty until the user needs to inject a character. 

Ah, indeed.

> >One way could be for brltty to quickly check from /dev/tty1 with
> >VT_GETSTATE whether some process is actually running on the new VT,
> >before opening /dev/tty0.  That will always succeed in normal operation,
> >it will fail when systemd-logind hasn't started getty on the VT yet,
> >thus preventing brltty from opening it.  
> 
> But isn't there still the risk that brltty opening tty1 for this purpose may 
> prevent systemd-login from starting getty on tty1?

systemd-login always starts getty on tty1.

> >Another scenario to consider is people who could be emitting data to some VT 
> >through e.g. a cronjob. An additional check that brltty could do after 
> >VT_GETSTATE would be checking whether /dev/vcsa is a blank screen.  In that 
> >case, there is indeed really nothing to do with the VT.
> 
> It could be that such an appliation simply hasn't written any data to the vt 
> yet. In other words, I believe that even a blank screen is significant to the 
> user in such a scenario, and, therefore, he must still be able to read it.
> 
> Is there no way for brltty to open a tty "secretly"?

Not for TIOCSTI ioctls.

Samuel