[BRLTTY] [PATCH 0/6] BC6xx usability enhancements

[Nicolas Pitre]

I'm starting to get used to work with an Alva BC640.  I still
highly regret my former Brailliant 40 which I think had more efficient
controls than the BC640.

This being said, I think that many things could be done to improve the
user experience with the BC640.  First of all, this double cursor
routing emulation is actually horrible.  To emulate an non existant
second row of cursor routing keys, the device let you hold a key and if
held long enough the second row key events is generated.  This makes the
normal first row bindings very awkward to use since their events are not
reported until the key is actually released.  This causes many problems:

1) If the routing key is not released quickly enough, the second row
   key event is generated.  Configuring a longer delay makes the
   bindings using the second row more annoying to use.

2) Releasing a key combination containing a routing key too quickly
   leads to unpredictable results as the thumb key may be released first
   while the press event for the routing key has still not been sent due
   to the waiting delay needed to distinguish between the first and
   second row emulation.  So, e.g. instead of doing a cut begin
   operation, you may get a window movement followed by a cursor
   tracking operation to some unexpected location which is very, very
   annoying.

3) Movement bindings currently using the second set of routing cursor
   keys are obnoxious as you need to wwaaaaiiiit for the emulation
   timeout to occur.  Unless you are an unseasoned braille display user,
   those extra delays are slowing you down in your operations, adding to
   the frustration.

Next, the bindings themselves are suboptimal.  Some movement bindings
are done with the thumb keys, and some others are done with the etouch
keys.  This makes busy screen navigation less optimal as the hands have
to move away from the thumb keys and back.  Furthermore, the thumb keys
are much more rugged than the etouch keys so it is best to put
frequent repetitive key actions on those and confine the more fragile
keys to miscelaneous functions such as copy/paste which are not
solicited as much.

So... I've reworked the bindings:

1) to make movement bindings more efficient

2) to remove any RoutingKey2 bindings

And finally, make the driver mask any RoutingKey2 event and turn them
into RoutingKey1 events.  So, even if the device still try to emulate
those non existant keys, the driver would still report those events as
being the same keys.  This way, all the bindings would work whether or
not the emulation feature is enabled in the BC640's configuration.
Things work better if the emulation is turned off, but even when turned
on the effect is then much predictable.

I really think that if we want to support this kind of behavior, that
should be implemented in BRLTTY rather than in the device.  For example,
to complement the ! key binding qualifier, we could introduce an
additional one that would denote a held key i.e. the binding would
be triggered by such a qualified key when it is held for more than a
certain delay.

Follows a series of patches providing the presented changes above.


Nicolas