[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: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org