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

Klaus Knopper brltty at knopper.net
Thu Jan 25 02:28:07 EST 2007


Hi Dave,

On Wed, Jan 24, 2007 at 08:21:40PM -0500, Dave Mielke wrote:
> [quoted lines by Klaus Knopper on 2007/01/24 at 18:15 +0100]
> 
> >- Possibility to use the screenreader WITHOUT a braille display, by
> >  using hotkeys on the normal keyboard for navigating and speaking he
> >  screen content. This is he most imporant feature.
> 
> I aassume you mean the ability to use brltty for speech only.

Not only for speech, also for virtual cursor navigation, cut&paste, and
possibly functions that are partly found in programs like "screen".

The main difference would be using the keyboard instead of a braille
device, hence the idea of just adding a "keyboard braille device" driver
with no output function, but input keys, which then can be used
standalone, or together with a real braille device. Mario told me that
the new versions of brlty are not depending on a device poll loop
anymore, so the screenreader is more or less independent from a real
braille device already.

> This could be
> fairly easily done. I've even thought of doing it before, but just haven't
> gotten around to it yet. What keys would you use on the keyboard?

With sbl, this is currently configurable via
/usr/lib/suse-blinux/keymaps/default; I added the feature of having
separate config files for keyboard and braille line. The base config
looks like this, the syntax is 
function=braillekey,keyboardkey
which is not necessarily the best idea because it limits the number of
real braille devices to one:

# init keys for keyboard-sniffer, we use capslock because it is present
# on all keyboards, and mst people hate its original effect. ;-)
kbdsniffon1=,caps_lock
kbdsniffoff=,caps_lock
# reset for brlport
resetbrl=,r
### navigation
lnup=B005,csrup
lndn=B006,csrdn
chrlft=,h
chrrgt=,l
### Speech functions
spktocsr=,csrlft
spkfromcsr=,csrrgt
spkcurln=,space
spkscrfromcsr=,pgdn
spkscrtocsr=,pgup
nextlang=,l
prevlang=,p
nextspd=
prevspd=
nextvol=
prevvol=
nextvoice=
prevvoice=
...

So, for example, if you press capslock and pagedown, sbl will speak from
the current cursor position to the bottom of the current page,
capslock and space would just (re)speak the current line.

> It'd be nice
> to use a scheme which wouldn't interfere with Speakup's bindings.

Is speakup needed for brlttys functioning? In our project, we would like
to use festival (because of quality), espeak (because of the small
footprint) with or without speech-dispatcher.

Anyways, if we use a configuration file for keyboard configuration, the
hotkey settings are user-configurable. I would like to use an initial
scheme that is similar to stuff like "Jaws" on Windows, so people who
are migrating have a good start, but again, the keyboard configuration
should stay entirely user-configurable.

> >- Disconnect/reconnect of bluetooth-connected braille devices without
> >  restarting the screenreader.
> 
> That's easy to do. Right now brltty waits for the braille display to come back
> because the display's controls are it's only source of input. Restructuring
> this isn't difficult.

Sunds very good. :-)

> >- Profiles for different programs/environments that are automatically
> >  activated.
> 
> This one is much more complicated. I doubt that sbl even gets it right. It's
> easy to know what the foreground program is when running in text mode right on
> the console. If accessing a remote system via telnet/ssh, however, or if using
> a GUI, determining which program is running in the current foreground is
> essentially impossble to determine passively.

Right, and this doesn't work in sbl either. even if using "screen"
locally, the real program profile isn't autodetected anymore. In this
case, there are keyboard hotkeys that allow you to switch from the
"bash" profile to "mutt", "elinks" or similar.

> >- Keyboard-operated cut&paste support between programs and consoles.
> 
> That's easy to do.

*grins* Whenever I used to say that, it took half a year to actually do
it. ;-)

> >- Multiple language/pitch/speed/volume support for the sofware speech
> >  synthesizer (festival) to be activated by keyboard shortcuts.
> 
> I think that's easy, although I'm not sure exactly what is needed here. If you
> mean dynamically changing settings depending on the current text then that's
> more difficult.

Just having hotkeys that allow you to change pitch and speed via the
keyboard would be fine, hough sbl also supports this in the profile
selection, so if you start a mail program, the sound sesstings can be
different from those in plain bash.

> If you just mean establishing settings then it's easy. Volume
> and speed are already handled. A default (startup) setting can be saved, and
> the current setting can be changed either via the preferences menu or via keys.

Great, so I assume it's already done. :-)

Would it be helpful if I send you my current sbl source so you can have
a look at it, or would you rather like to just point me to the right
place to start implementing a keyboard driver in the brltty source?

I may sound like a fast starter, but in fact, I'm just excited. ;-)
Actually, I won't be able to do anythung until we return from India in
beginning of February.

Regards
-Klaus Knopper


More information about the BRLTTY mailing list