On Wed, 18 Jan 2017, Dave Mielke wrote: > [quoted lines by Nicolas Pitre on 2017/01/18 at 11:53 -0500] > > >If speech is enabled then I think it makes sense for autospeak to be > >active by default, especially if there is no braille display. > > If the braille device isn't connected then autospeak should already be > enabled > by default. This, of course, can't be detected if the connection is via a > serial port. To keep autospeak off when there's no braille device you need to > specify -Q (upperase) or --quiet-if-no-braille. > > Are you saying that you believe the default for autospeak - assuming that it > hasn't been explicitly set yet - should be on?
I would say so. Especially if there is already -Q to negate that behavior. > >This is still a reliability issue. Having doubles typed letters means > >BRLTTY is delaying the forwarding of key release events and that's bad. > >The keyboard filtering should probably be relegated to a thread of its > >own to avoid this problem. > > Yes, this can be done. I thought that the problem had been resolved after > having moved speech and alert tunes to their own threads. Well, at least in the alert tune case this made the tunes less susceptible to audible drifts even if the primary goal was to avoid blocking the rest of BRLTTY during playback. Keyboard filtering could benefit from that reliability enhancement as well, especially on slower devices. Nicolas _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.com/mailman/listinfo/brltty
