[BRLTTY] Bluetooth

[Stéphane Doyon]

On Thu, 17 Jan 2008, Dave Mielke wrote:

> [quoted lines by Stéphane Doyon on 2008/01/16 at 23:52 -0500]
>
>> This is of course somewhat clunky. The right thing to do would probably be
>> for BRLTTY to register as an agent over dbus and provide the PIN directly.
>
> Yes, this is something I'd like to do. Please, all, give me your ideas on how
> we should be telling brltty what the braille display's bluetooth pin is.

I would have the PIN as part of the configuration. Unless I'm missing an 
important use case, I don't see any point in trying to prompt for it, 
since the user is most likely trying to get his display working and 
probably has no way to read the prompt. Plus you want this working as 
early as possible at boot... well I suppose we're already depending on the 
whole bluetooth stack having come up...

One idea: put it in the device specifier.
braille-device usb:,bt:00:A0:00:00:00:FF/1234
That way you can conceivably manage multiple bluetooth displays.
It puts the secret in your brltty.conf however, so you would want the 
installation to make that file mode 0600.

Alternatively, add a bt-pass-key option that might look like this:
bt-pass-key bt:00:A0:00:00:00:FF/1234
So that maps BT addresses to PINs.
Allow having that option specified multiple times.
Add an inclusion mechanism to brltty.conf parsing, by which sub config 
files can be sourced. Put bt-pass-key in a separate config file with mode 
0600, and brltty.conf can remain readable. Not sure this added complexity 
really helps though, so I might prefer the first option.

>> One glitch I've had is if the USB bluetooth dongle is disconnected: brltty
>> keeps writing to the dead bluetooth interface indefinitely, all the while
>> flooding your log with "Transport endpoint is not connected". The attached
>> patch is my quick&dirty fix for this: perhaps this could be better done
>> at a higher level that would apply to all drivers?
>
> Can you please see if there's a way to trap the error on the read instead of on
> the write so that BRL_CMD_RESTARTBRL can be returned without support for a
> pending command?

Well... as I said, brltty just kept going. That would seem to imply that 
there were no read errors. Is there something specific I should try?

Instead of adding support for pending commands, perhaps we could define an 
error case for brl_writeWindow() that would cause a reset, or add an error 
or reset field to the BrailleDisplay structure?

-- 
Stéphane Doyon
<s.doyon at videotron.ca>
http://pages.videotron.com/sdoyon/