APH Refreshabraille 18 has braille input problems. #3541

Closed
nvaccessAuto opened this Issue Sep 21, 2013 · 9 comments

2 participants

@nvaccessAuto

Reported by ianr on 2013-09-21 23:54
I am using the native NVDA braille driver labelled Baum/HumanWare/APH braille displays with an APH Refreshabraille 18.
Specifically I have noticed these 3 issues in NVDA 2013.2:
1 The braille input buttons stop working completely after the stick is moved up, down, left, right, or pressed, or any routing key is pressed, or the forward and back keys located on the left and right sides directly under the routing keys are pressed.
They can be fixed by entering the NVDA Braille settings dialog and pressing the OK button, but will stop working again any time you use the stick or routing keys.

2 Sometimes after pressing the buttons to output a computer braille g, meaning dots 1,2,4,5, the g will not be output, but next time I press any of the 6 braille input buttons the g will be output and the input key I just entered is ignored.

3 When pressing the bottom left most key on the display \7/ is output, and when pressing the bottom right most key \8/ is output.
This last item can probably be solved by manually mapping these keys to commands using the gestures.ini file.

I'll admit I am not overly familiar with braille input and am assisting a teacher of the blind and visually impaired.
So my apologies if I'm missing something obvious and there is some simple way to switch back into braille input mode.
My search of the APH documentation has so far not mentioned this.
Thanks in advance.

Blocking #2928, #3716

@nvaccessAuto

Comment 1 by jteh on 2013-09-22 00:19
Unfortunately, I don't actually have access to any Baum display with a braille keyboard, so fixing this is going to be very difficult if not impossible for me.

When braille input stops working, what do you hear if you press braille keys while in input help mode (NVDA+1)?

@nvaccessAuto

Comment 2 by ianr on 2013-09-22 00:32
Ah! It changed!
I've pasted a snippet from the log for preciseness:
Loaded braille display driver baum, current display has 18 cells.
INFO - inputCore.InputManager._handleInputHelp (18:24:12):
Input help: gesture br(baum):b1, bound to script braille_dots on globalCommands.GlobalCommands
INFO - inputCore.InputManager._handleInputHelp (18:24:31):
Input help: gesture br(baum):up, bound to script kb:upArrow
INFO - inputCore.InputManager._handleInputHelp (18:24:33):
Input help: gesture br(baum):b1

As you can see I press B1, then the stick up, then B1 again.
The first time I get the extra help information about B1 and the second time I do not.
Thanks for your quick response.

@nvaccessAuto

Comment 3 by jteh on 2013-09-22 23:46
Looking at the code, the only way I can think of that this might happen is if the display is telling us that an unknown key is pressed but it never tells us when that key is released. I can try to hack around this, but first, I'm going to try to see if I can finally get hold of someone at APH so I can get some technical documentation and maybe a display, as this is not the first problem I've heard of regarding NVDA and the RefreshaBraille.

@nvaccessAuto

Comment 6 by jteh on 2015-06-16 07:09
Changes:
Milestone changed from None to 2015.3

@nvaccessAuto

Comment 7 by James Teh <jamie@... on 2015-06-16 07:16
In [78e13e3]:
```CommitTicketReference repository="" revision="78e13e33d0d4cdbe2ee7b70bd3773363777568af"
When using Baum/HumanWare/APH braille displays with a braille keyboard, braille input no longer stops functioning after pressing another type of key on the display.

When all keys for a group were released, a 0 was still being set in the keysDown dict for that group. However, when testing for braille input, we count the number of groups in keysDown, assuming that groups with no keys down are not present at all.
To fix this, remove a group altogether when all keys are released.
Re #3541.

@nvaccessAuto

Comment 8 by James Teh <jamie@... on 2015-06-16 07:17
In [c5e59ea]:
```CommitTicketReference repository="" revision="c5e59ead8c46f56b8a9cf515cf000cd3fa96841a"
Merge branch 't3541' into next

Incubates #3541.

Changes:
Added labels: incubating
@nvaccessAuto

Comment 9 by jteh on 2015-06-16 07:25
A fix for this will land in the NVDA "next" snapshot for 16 June, which should be available from the snapshots page in a few hours. Please let me know if there are any issues.

Special thanks to APH for providing me with a Refreshabraille to test with.

@nvaccessAuto

Comment 10 by James Teh <jamie@... on 2015-06-17 04:19
In [56fc894]:
```CommitTicketReference repository="" revision="56fc89467601ae8e9088053178f99b22fb4340f6"
Merge branch 't3541' into next: Minor cosmetic tweaks.

Incubates #3541.

@nvaccessAuto

Comment 11 by James Teh <jamie@... on 2015-07-01 03:40
In [519c8b3]:
```CommitTicketReference repository="" revision="519c8b374beb0b3c9b3c70942c45309ab584137f"
When using Baum/HumanWare/APH braille displays with a braille keyboard, braille input no longer stops functioning after pressing another type of key on the display.

Fixes #3541.

Changes:
Removed labels: incubating
State: closed
@jcsteh jcsteh was assigned by nvaccessAuto Nov 10, 2015
@nvaccessAuto nvaccessAuto added this to the 2015.3 milestone Nov 10, 2015
@jcsteh jcsteh added a commit that referenced this issue Nov 23, 2015
@jcsteh jcsteh When using Baum/HumanWare/APH braille displays with a braille keyboar…
…d, braille input no longer stops functioning after pressing another type of key on the display.

When all keys for a group were released, a 0 was still being set in the keysDown dict for that group. However, when testing for braille input, we count the number of groups in keysDown, assuming that groups with no keys down are not present at all.
To fix this, remove a group altogether when all keys are released.
Re #3541.
78e13e3
@jcsteh jcsteh added a commit that referenced this issue Nov 23, 2015
@jcsteh jcsteh When using Baum/HumanWare/APH braille displays with a braille keyboar…
…d, braille input no longer stops functioning after pressing another type of key on the display.

Fixes #3541.
519c8b3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment