Bug#760916: brltty interferes with getty autostart

[Dave Mielke]

[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. 
This could be by typing on the braille device, by requesting cursor routing, 
etc. The user probably wouldn't do any of that until the login prompt appears.

>Whatever the timing, there is a risk that systemd-logind gets slow for
>some reason, and not manage to start getty before brltty opening it.

Perhaps, but the user is unlikely to do much before seeing the login prompt.

>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?

>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"?

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: dave at mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.com/