Bug#760916: brltty interferes with getty autostart
[quoted lines by Michael Biebl on 2016/12/16 at 05:59 +0100] >could you give me an update on this issue? Is this still an issue? No, it isn't. It was fixed almost exactly a year ago. The fix is in brltty 5.4 for sure. -- 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.org/
Bug#760916: brltty interferes with getty autostart
On Wed, 21 Jan 2015 18:56:42 -0500 Dave Mielke wrote: > [quoted lines by Samuel Thibault on 2015/01/22 at 00:46 +0100] > > >Reading is fine, since it's done through /dev/vcsa, which doesn't count > >in VT_GETSTATE. > > Not exactly. The tty device still needs to be opened in order to do things > like > fetch the Unicode map. > > It's possible, of course, that things like the Unicode map, the screen font > map, the character translation table, etc are common to all vts, in which > case > they could be fetched from tty1. I'm not familiar enough with the internals > to > know for sure. > > I noticed a comment in the source for systemd-logind stating that tty1 is > special, so using it would seem to be okay. We still need to be sure that all > of what we need for mapping the font positions returned by the vcs devices > back > to the original characters is common to all ttys so that fetching them from > tty1 would be valid for other ttys. Hi Samuel, hi Dave, could you give me an update on this issue? Is this still an issue? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#760916: brltty interferes with getty autostart
Dave Mielke, le Wed 21 Jan 2015 18:56:42 -0500, a écrit : > It's possible, of course, that things like the Unicode map, the screen font > map, the character translation table, etc are common to all vts, They are not :/ Samel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
[quoted lines by Samuel Thibault on 2015/01/22 at 00:46 +0100] >Reading is fine, since it's done through /dev/vcsa, which doesn't count >in VT_GETSTATE. Not exactly. The tty device still needs to be opened in order to do things like fetch the Unicode map. It's possible, of course, that things like the Unicode map, the screen font map, the character translation table, etc are common to all vts, in which case they could be fetched from tty1. I'm not familiar enough with the internals to know for sure. I noticed a comment in the source for systemd-logind stating that tty1 is special, so using it would seem to be okay. We still need to be sure that all of what we need for mapping the font positions returned by the vcs devices back to the original characters is common to all ttys so that fetching them from tty1 would be valid for other ttys. -- 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
Bug#760916: brltty interferes with getty autostart
Dave Mielke, le Wed 21 Jan 2015 18:43:09 -0500, a écrit : > There's another case where brltty needs to "see" a vt when it isn't open. For > example, a command can be run asynchronously in a free vt via the openvt > command. After the command finishes, the output remains on the vt's screen > even > though the vt itself has been closed. The user needs to still be able to > switch > to that vt and read it. Reading is fine, since it's done through /dev/vcsa, which doesn't count in VT_GETSTATE. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
There's another case where brltty needs to "see" a vt when it isn't open. For example, a command can be run asynchronously in a free vt via the openvt command. After the command finishes, the output remains on the vt's screen even though the vt itself has been closed. The user needs to still be able to switch to that vt and read it. -- 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
Bug#760916: brltty interferes with getty autostart
Dave Mielke, le Wed 21 Jan 2015 17:08:00 -0500, a écrit : > Do either of you know how often systemd-login retries, and how many times it > tries before giving up? I don't think it retries. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
Do either of you know how often systemd-login retries, and how many times it tries before giving up? What we could do is open the vt on demand, and then close it after a timeout of non use. -- 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
Bug#760916: brltty interferes with getty autostart
[quoted lines by Dave Mielke on 2015/01/20 at 00:34 -0500] >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. I just checked. It turns out that brltty actually does need to open the vt right away. For example, it uses GIO_UNIMAP to retrieve the Unicode map so that it can back translate font positions into characters in order to determine what's on the screen. It also uses VT_GETHIFONTMAKS in order to know how to interpret the attributes bytes. Yet another thing it does is use VT_GETSTATE in order to determine which vt is active (vt_stat.v_active). Even open on demand, therefore, would result in the tty being opened almost immediately. -- 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
Bug#760916: brltty interferes with getty autostart
[quoted lines by Dave Mielke on 2015/01/20 at 20:32 -0500] >On my Fedora systems - which are managed by systemd - X starts on tty1. As I understand it, X also wants a free vt. Why is it, then, that X is willing to start on tty1 (at least on Fedora systems) even though brltty already has tty1 open? How does X decide that tty1 is still free? -- 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
Bug#760916: brltty interferes with getty autostart
[quoted lines by Samuel Thibault on 2015/01/21 at 01:10 +0100] >> 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. On my Fedora systems - which are managed by systemd - X starts on tty1. Of course, X doesn't start till later, so, for most of the boot, nothing is running on tty1. Something else to consider is the desire for brltty to start as soon as possible. Ideally, it should be able to start before things like the fscks so that a braille user can manage his own system failures. This, of course, would be way before any getty would be started. I suspect that vt_stat would be 0 at this point, so we either disallow a braille user to deal with early boot problems or we need to dream up some other approach. -- 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
Bug#760916: brltty interferes with getty autostart
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
Bug#760916: brltty interferes with getty autostart
[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
Bug#760916: brltty interferes with getty autostart
Dave Mielke, le Mon 29 Dec 2014 12:04:19 -0500, a écrit : > We could open it on demand rather than immediately? On which demand? 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. 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. 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. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#760916: brltty interferes with getty autostart
Hi: We could open it on demand rather than immediately? -- 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
Bug#760916: brltty interferes with getty autostart
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
