[BRLTTY] Chords in brlapi

[Peter Nilsson Lundblad]

Dave Mielke writes:
> [quoted lines by Peter Nilsson Lundblad on 2014/02/11 at 14:17 -0800]
> 
> >I'd like to get access to chords (space plus dots) thought brlapi.
> >I am setting the retaindots flag to yes in the api parameters and I
> >get other dot combinations though the BRLAPI_KEY_CMD_PASSDOTS command.
> >I had the impression that the BRLAPI_DOTC flag would be set in the
> >argumets bits for chords, but that's not what I am seeing.
> 
> Your impression is correct except that this feature isn't working very well 
> anymore. It's really an old feature which dates back to before key tables. It 
> made sense, then, since there needed to be a way to tell the drivers to return 
> the space bar (chord key).
> 
> These days, however, with key tables, this feature really doesn't make all that 
> much sense anymore as it has everything to do with hard-coded key bindings. 
> Commands, these days, should be defined in key tables. I'm almost of the 
> opinion that it's time to fully remove the retainDots feature. Is there an 
> actual case which would justify its revival?
> 
There are two use cases for retainDots:

1. To get raw dots instead of characters as input.  If using e.g. liblouis as a translator, this is necessary, otherwise we'd be using brltty's tables for input and liblouis for output which would be inconsistent and also not support anything but non-contracted computer braille.  Ideally, an api client would be able to choose at runtime if it wants braille cells or characters instead of relying on a system-wide flag, but that's slightly off topic.  I think we need to keep this part of the feature, and according to my testing it seems to keep working.

2. "Raw" chords could be one way of extending the available command set beyond the ones that brltty provides for displays that support chords without loosing the rest of brltty's keymap functionality. The idea would be that an api client would handle its own mappings for chords on its level (since they use similar keys on all displays that have braille keyboards), while navigations keys etc. which vary significantly between displays would be taken care of by brltty's existing mappings.  I don't think this is a strong enough argument to ressurect this feature if we could find another way of extending the command set for different api clients.

So I think my conclusion is that we need to keep the ability to get raw
braille cell input, while we might need to find a better solution for what I describe in point 2 above.

Thanks,
//Peter