Comment 1 by nvdakor on 2015-05-11 18:25
Hi there,
Is the display set to use BAUM protocol? If so and if the issues reported still persists, then we may need to do some investigation into this matter.
One thing that we can try is to see if you can supply us with the documentation for the Refreshabraille API - that is, the protocol used by the display for keyboard input, braille display output and so on so we can colaborate on writing a customized braille display driver to interface with Refreshabraile 18. For a sample implementation, please take a look at NVDA source code under braille display drivers directory, preferably Baum displays.
Thanks.

Comment 2 by wfreeman on 2015-05-19 15:37
Hello,
We are using the BAUM protocol and the problem still persists. I would like to send you our documentation for the Refreshabraille API. Do you have an e-mail address I may send this information to?

Thanks,
William

Comment 3 by nvdakor on 2015-05-19 15:58
Hi,
Please send relevant documentation to jamie@nvaccess.org. Please CC me at joseph.lee22590@gmail.com so I or Jamie can start work on custom braille display driver for Refreshabraille 18 to be included as early as this summer. Or, a better way would be to let someone at your end to write NVDA braille display driver for Refreshabraille 18 as a patch (Python is used, please test it with a demo unit) so we can include it as part of future NvDA releases. That way, you can also get credit for this project.
Thanks.

Comment 4 by jteh (in reply to comment description) on 2015-05-20 00:00
Thanks for your interest. We've actually not had any contact with anyone at APH regarding this display despite several concerns from users, so I'm glad you made contact.

Replying to wfreeman:

I've tested out the Refreshabraille 18 with NVDA and found that the only means of navigation are using the directional button and the advance bars. None of the usual shortcut keys work, like chord+dot 1, chord+dot 4,

When you say "usual shortcut keys", are these documented in the Refreshabraille manual as being common across all screen readers? From what I've seen with other displays, they usually document the bindings for each screen reader separately, though there are commonalities, of course.

or chord+h.

This presents a localisation issue. Chord+h is probably only meaningful in English. Aside from this, it's not currently possible to bind to space+h, which means we'd have to bind to space+dot1+dot2+dot5.

There's some debate as to whether we should unify braille chord commands for all displays with NVDA, rather than each display implementing its own chords. The advantage is that it allows for common braille input commands, etc.

Still, if you can suggest bindings and what they should do, I'd be happy to consider adding them in the interim. Note that this will affect all displays using the Baum protocol, but i doubt anyone will object.

The other issue is that while you can type with the Refreshabraille 18 using NVDA, you can't delete or hit enter. Pressing dot 7 causes \7/ and pressing dot 8 causes \8/.

That would need to be a specific binding for now as well.

You can technically hit enter by pressing the directional button but doing so causes you to lose the ability to type until you go into the braille settings and refresh your braille device.

This is probably #3541; see that ticket for details.

Is it something that needs to be fixed on our end or is there information we can supply you with that would allow you to increase the functionality between our device and your software?

See above regarding information about bindings. I would also need technical documentation (which it seems you are already going to provide if you haven't already). If I'm going to investigate/fix bugs like #3541, I need access to a Refreshabraille for at least a month. It's just not possible to debug some of these issues without physical access to a display.

Btw, I think a separate driver for this display is unnecessary. Most of these issues will be common to all Baum-based displays.

Hello. With the Orbit Writer and other displays, I notice that the Baum driver is still sparse on key bindings compared with some of the other displays. I'm willing to submit a PR for a more elaborate set of bindings to bring it in line with Focus/Brailliant/etc. but wanted to see if there was any reason this would not be desirable.