Bug#760916: brltty interferes with getty autostart

2016-12-15 Thread Dave Mielke
[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

Bug#760916: brltty interferes with getty autostart

2016-12-15 Thread Michael Biebl
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 >

Bug#760916: brltty interferes with getty autostart

2015-01-21 Thread Samuel Thibault
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.or

Bug#760916: brltty interferes with getty autostart

2015-01-21 Thread Dave Mielke
[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 l

Bug#760916: brltty interferes with getty autostart

2015-01-21 Thread Samuel Thibault
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

Bug#760916: brltty interferes with getty autostart

2015-01-21 Thread Dave Mielke
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

Bug#760916: brltty interferes with getty autostart

2015-01-21 Thread Samuel Thibault
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 "unsubscr

Bug#760916: brltty interferes with getty autostart

2015-01-21 Thread Dave Mielke
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 |

Bug#760916: brltty interferes with getty autostart

2015-01-20 Thread Dave Mielke
[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.

Bug#760916: brltty interferes with getty autostart

2015-01-20 Thread Dave Mielke
[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 op

Bug#760916: brltty interferes with getty autostart

2015-01-20 Thread Dave Mielke
[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 -

Bug#760916: brltty interferes with getty autostart

2015-01-20 Thread 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, in

Bug#760916: brltty interferes with getty autostart

2015-01-19 Thread 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, e

Bug#760916: brltty interferes with getty autostart

2014-12-29 Thread Samuel Thibault
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

Bug#760916: brltty interferes with getty autostart

2014-12-29 Thread Dave Mielke
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,

Bug#760916: brltty interferes with getty autostart

2014-12-29 Thread Samuel Thibault
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 normall