Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

APH Refreshabraille 18 has braille input problems. #3541

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

APH Refreshabraille 18 has braille input problems. #3541

nvaccessAuto opened this issue Sep 21, 2013 · 9 comments
Assignees
@jcsteh
Labels
bug component/braille
Milestone
2015.3

Comments

@nvaccessAuto
Copy link

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@nvaccessAuto
Copy link
Author

Comment 7 by James Teh <jamie@... on 2015-06-16 07:16
In [78e13e3]:

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
Copy link
Author

Comment 8 by James Teh <jamie@... on 2015-06-16 07:17
In [c5e59ea]:

Merge branch 't3541' into next

Incubates #3541.

Changes:
Added labels: incubating

@nvaccessAuto
Copy link
Author

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
Copy link
Author

Comment 10 by James Teh <jamie@... on 2015-06-17 04:19
In [56fc894]:

Merge branch 't3541' into next: Minor cosmetic tweaks.

Incubates #3541.

@nvaccessAuto
Copy link
Author

Comment 11 by James Teh <jamie@... on 2015-07-01 03:40
In [519c8b3]:

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

@nvaccessAuto nvaccessAuto added this to the 2015.3 milestone Nov 10, 2015
This was referenced Nov 10, 2015
Closed
Open
jcsteh added a commit that referenced this issue Nov 23, 2015
@jcsteh
When using Baum/HumanWare/APH braille displays with a braille keyboar…
78e13e3 
…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.
jcsteh added a commit that referenced this issue Nov 23, 2015
@jcsteh
When using Baum/HumanWare/APH braille displays with a braille keyboar…
519c8b3 
…d, braille input no longer stops functioning after pressing another type of key on the display.

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

@jcsteh jcsteh

Labels
bug component/braille
Projects
None yet
Milestone
2015.3
Development

No branches or pull requests
2 participants
@jcsteh @nvaccessAuto