[BRLTTY] autospeak=yes and using BRLTTY without braille display

[Nicolas Pitre]

On Wed, 18 Jan 2017, Dave Mielke wrote:

> [quoted lines by Sebastian Humenda on 2017/01/18 at 16:59 +0100]
> 
> >This is something I find quite problematic, especially when using computers 
> >with a braille display I don't know. In such cases it's hard to open the 
> >preferences menu and having speech would e.g. speed up reading the keyboard 
> >table of the display.
> 
> I understand the problem, but I don't think forcing autospeak on if a speech 
> driver has been selected is a good thing to do. Many users want speech on 
> demand and wouldn't appreciate it being imposed on them.
> 
> I'm open to suggestions, though. I'm not a speech user so it's entirely 
> possible that my understanding of all of the issues isn't very good.  Perhaps 
> others can comment on this issue as well.

If speech is enabled then I think it makes sense for autospeak to be 
active by default, especially if there is no braille display.

Another solution that would avoid any semantic issues is the ability to 
override default/saved preference menu options from the command line. 
Something like:

	brltty -o autospeak=yes -o autospeak-completed-words=no ...

The same keywords as found in the brltty.prefs file could be used.

> >When I start my computer without a braille display, I find that BRLTTY is very
> >unresponsive and does sometimes delay actions or doubles typed letters. This
> >does not happen when I start BRLTTY explicitly with `-b no` or with a braille
> >display is attached. I suppose this has to do with BRLTTY searching for a
> >display.
> 
> Yes, that's what it seems like. An additional test would be to try using -b to 
> specify the specific driver but not have the braille device connected. I 
> suspect that'd be a lot better because brltty is then only trying one driver 
> instead of trying to autodetect all of them.

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.


Nicolas