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

[Klaus Knopper]

On Thu, Jan 25, 2007 at 03:00:25AM -0500, Dave Mielke wrote:
> [quoted lines by Klaus Knopper on 2007/01/25 at 08:28 +0100]
> 
> >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. 
> 
> If there isn't any output device, how would the user know what he's doing? 
> Perhaps I'm just slow at catching on to a new concept, but what use would it be
> to have navigation functions which have no way of giving any user feedback?

Soundcard, text-to-speech! Thought I wrote that before.
Keyboard for navigation, TTS only for output. It works extremely well
with sbl, we already tried.

Advantage, of course, is that blind people who have no way of affording
a braille device, can still use a cheap/old computer.

> >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.
> 
> That's essentially true, although none of the drivers have been converted yet. 
> Monitoring the keyboard for asynchronous events, however, is easy to add.

sbl uses a small kernel patch for getting direct access to the keyboard
queue without interfering with running programs. Maybe that kernelpatch
is even unnecessary.

> >> 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.
> 
> I certainly wouldn't want to do anytghing which prevents brltty and speakup
> from coexisting since I believe in giving users the freedom to mix and match as
> they themselves would prefer. If a user would like to use brltty and speakup
> together then he should be able to do so.

Right. Therefore the keyboard shortcuts must be configurable. Pressing
the configured hotkey for enabling keyboard navigation input should then
make sure that no other program is affected by the same key combination.

> >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.
> 
> Application-specific profiles are an interesting idea, but are they really all
> that useful? Maybe I'm just used to working for so long without them. In any
> event, I have a hard time getting interested in features which only work in
> certain cases.

Well,for programs that have profiles, the profile is used. For those
that have none, the defaultprofileis used.

It's just a good feature for automatic cursor tracking and
program-specific settings.

> Perhaps they could be made to work better if, rather than asking
> the system what the foreground program is, they pattern-match the screen
> content/highlighting for application-specific appearances.

I THINK that sbl looks for the program name attached to the current virtual
console. But even in the "default" profile, you can define up to four
attribute settings that can trigger the braille/sound output focus,
which affects especially ncurses-based programs.

In a practical example, the profiles make sure that the screenreader
reads the highlighted links automatically in elinks or lynx, where it
just ignoresthe same attributes in a chat program, and monitors
different areas of the screen in different programs,which I find is a
very essential feature also when using a braille device.

> >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 don't think a keyboard driver is the right way to do it. A keyboard monitor
> would be much better. I shall think about it for a bit.

Please let me know as soon as you have a hint in which direction to go.
:-)

I just thought that handlingthe keyboard like a new "input-only"device
would be easier than implementing a completely new concept running
parallel to braille drivers.

-Klaus