[BRLTTY] brltty "keyboard braille device" support (and a few more things)

[Mario Lang]

Dave Mielke <dave at mielke.cc> writes:

>>What is the "system clipboard" ? Didn't know such a thing exists under
>>Unix. 
>
> I don't know what it's official name is, but, unless I'm overinterpreting the
> requirement, I think what's being asked for is the ability to cut with brltty
> and paste with gpm, etc. Linux has a shared cut buffer for this.

I think this is a misunderstanding.  I think Klaus really
ment "paste between consoles".  gpm actually implements exactly
the same thing as BRLTTY does, it doesn't make much sense to me
to be able to paste something cut'ed with BRLTTY with gpm.
If someone is already using the mouse, they might as well
cut using the mouse as well.

If we make cut and paste available via the keyboard, we will need
some way to mark the area, since we do not have routing keys available.
Speech only use would require some kind of reading cursor anyway,
that might be used to mark the area in question as well.

Regarding the whole keyboard-only issue, to me, it would make
much sense to add this to BRLTTY for the following reasons:

* It would be neat to be able to use a laptop for instance temporarily
  without a braille display connected.  Currently, on linux, thats
  only possible by using a completely different screen reader like
  yasr or screader.  This is not exactly comfortable, since
  the user would need to know how two screen readers work, just
  for this temporary case...  I can think of some concret situations
  that match this, like:
  * Your display battery ran out, and you forgot to carry the charger
    with you.  Some displays (like the HandyTech Braille Star)
    can not be charged via USB.  If you are using a mobile setup,
    it is desireable to be able to continue working, instead of being stuck.
  * A 80 cell display owner might want to use the display with their laptop
    while at home, and only use speech while being mobile.
* It would also add a safety net for exceptional situations
  where you for instance loose your display for some time.  Either
  because it is being repaired, or you misconfigured something
  and you are now trying to fix it.  If brltty had a speech-only
  mode, upon failure to init the display, the user would not
  be left in a complete void, but could still do something based
  on speech feedback.

To summarize, for this item, I think we need:
* A keyboard input module, using the input layer and uinput.
  I remember we need this anyway for some type of display that does
  not have keys.
  Since I've already looked at uinput for the
  HandyTech external keyboard thingy, I would volunteer to start 
  implementing this.
* Some kind of binding config file to configure what keys on the keyboard
  to bind to what BRL_ command.
  I think if we use keyboard input, we really need to make
  this user configurable from the beginning on.
* A "soft"-cursor, that can be manipulated from the keyboard, and
  which is used to determine what should be spoken.  This is more or
  less the same as we have with display window position right now, just
  think of a 1x1 display.  Move up/down/left/right.  Either speak
  the line, or char, or word.  Thats basically what other
  speech based screen readers do.  We'd need commands like
  reading cursor up/down,
  left/right one char
  left/right one word
  speak: line at pos, word at pos, char at pos, spell word at pos.

  Since we already have some rudimentary gpm support, we could
  even try to make the gpm cursor follow this "soft"-cursor, so that
  shighted users could see what the blind user is "looking" at.
* Bindings for marking cut areas that are based on this "soft"-cursor
  position.  I.e. begin/end rect/linear cut at pos...

To me, this would be nice addition.  Talking to users on
the Karlsruhe meeting definitely showed this is a *wanted* feature.
This is one of the main reasons why some people are using
sbl instead of brltty.  Since sbl doesn't have BrlAPI,
for the sake of compatibility, it would be highly desireable
to be able to atracted braille display users
towards brltty, so that they can benefit from the shared device
IO feature provided by using BrlAPI and graphical screen readers.

-- 
CYa,
  Mario