[BRLTTY] Get rid of braille display keys occasionally not working

[Lars Bjørndal]

Hi, Mario!

Thanks a lot for your detailed replay!

You wrote:

> Lars Bjørndal <lars at lamasti.net> writes:
> 
> > On Fri, Aug 11, 2017 at 11:17:38AM +0200, Lars Bjørndal wrote:
> >> Hi, Mario!
> >> 
> >> Another note:
> >> 
> >> On the system where I have connection problems, I sometimes experience
> >> that a key press on the braille display doesn't do anything. The
> >> display, however, moves when the cursor is moved.
> >> 
> >> Some lines from the log says:
> >> 
> >> aug. 11 05:06:56 kul3 brltty[1032]: input byte missing at offset 0
> >> aug. 11 05:06:56 kul3 brltty[1032]: Partial Packet: 79
> >> aug. 11 05:07:21 kul3 brltty[1032]: autoreleasing key: ? (Grp:0 Num:2)
> >> aug. 11 05:07:21 kul3 brltty[1032]: autoreleasing key: B3 (Grp:0 Num:11)
> >> aug. 11 05:07:21 kul3 brltty[1032]: autoreleasing key: ? (Grp:0 Num:22)
> >> aug. 11 05:07:21 kul3 brltty[1032]: autoreleasing key: ? (Grp:0 Num:84)
> >> aug. 11 05:07:21 kul3 brltty[1032]: autoreleasing key: ? (Grp:0 Num:85)
> >> aug. 11 05:08:43 kul3 brltty[1032]: input byte missing at offset 0
> >> aug. 11 05:08:43 kul3 brltty[1032]: Partial Packet: 79 54 02
> >> aug. 11 05:09:03 kul3 brltty[1032]: autoreleasing key: ? (Grp:0 Num:22)
> >
> 
> [...]
> 
> > The BRLTTY release is 5.5. I use a Handy Tech Active Braille.
> >
> > Please tell me if I can do anything more to investigate the keys not
> > working problem. In the mean time, I have to restart BRLTTY from time
> > to time, to get the keys working again.
> 
> I know that a slightly unstable Bluetooth connection can lead to lost
> key presses (or releases).  This was the reason why Dave implemented
> auto key release in BRLTTY 5.5.  What that does is to automatically
> release keys that have been pressed for a seemingly long time.  This,
> at least for me, made the issue of having to restart BRLTTY due to a
> lost key release go away.  When this happens, I just wait a few seconds
> until BRLTTY automatically releases the stuck key, and I can continue to
> work as usual.  However, I should probably also explain that I have
> changed my Bluetooth host controller chip in the meanwhile, from an USB
> dongle that used to be connected to my Pi Zero, to the internal
> Bluetooth chip that comes with the new Pi Zero W.  That change resulted
> in a more stable bluetooth connection.  I am using an Active Star
> though, so we can't really compare our results.

I use the built in bluetooth chip in the Rpi3.

> While I can not really be sure, I am guessing that most Bluetooth
> problems around Raspberry setups actually come from unstable hardware on
> the Raspberry side.  Even the USB port of a "full-blown" Raspberry Pi 3
> feels a bit weak to a Handy Tech user.  When I connect my Modular
> Evolution directly to the USB port of a Raspberry Pi 3, things basically
> work fine, but the Modular Evolution resets itself (with an audible
> beep) every 10 or 20 minutes.  To me, this indicates some problems with
> power, since I have never seen that behaviour with a normal PC USB port.

I haven't experienced that, but I have only had the ME88 connected for
a few minutes. But the AB40 behaves a bit slow when connected to the
USB port on Rpi3.

> To answer your question: All I can suggest is to try and switch
> to a differen bluetooth host controller, and, check in the BRLTTY
> preferences how long auto key release is set for you.  Experiment
> with that setting, maybe it helps.  This only makes sense though, if
> your Bluetooth connection is at least stable enough to basically work,
> but only sometimes loose a key event.  If it is unstable to a point
> where too much data gets lost, I am afraid there is not much really
> we can do on the side of BRLTTY to imrove that.

Auto key event was set to 20, and now I've changed it to 5.

In the /etc/bluetooth/main.conf I found a setting:

# Permanently enables the Fast Connectable setting for adapters that
# support it. When enabled other devices can connect faster to us,
# however the tradeoff is increased power consumptions. This feature
# will fully work only on kernel version 4.1 and newer. Defaults to
# 'false'.
#FastConnectable = false
FastConnectable = true

Do you think it makes sence to change this setting to true?

Thanks and regards, Lars