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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org