Skip to content

NLS E-Reader Zoomax braille display should possibly be supported by NVDA, but isn't #15863

Closed

Description

@XLTechie

Steps to reproduce:

Connect the Zoomax 20 cell braille display, which is one of the two units distributed in the U.S. as National Library Service free e-readers. Connect it via USB.

Actual behavior:

NVDA does not detect the display, even after restart. In USB mode, the display continues displaying "USB", as if it is waiting for connection.

Expected behavior:

I would hope this unit would be supported by NVDA, as its manual (for firmware version 2.0) claims NVDA support. That implies it was tested with NVDA at some point, and worked. Obviously, third party claims of NVDA support are meaningless if NVDA does not also claim support, but it's possible this display was known to work in the past, and has since stopped working.

Additional context:

The NVDA UG, in section 16.9, claims support for the NLS E-reader. I can only assume, that since this appears in the HumanWare section, that support only applies to the HumanWare version of the NLS e-reader.

NVDA logs, crash dumps and other attachments:

Here is a log, with HWIO logging enabled.
nvda-nobraille.txt

System configuration

NVDA installed/portable/running from source:

Installed

NVDA version:

2023.3

Windows version:

11, 22H2

Name and version of other software in use when reproducing the issue:

N/A

Other information about your system:

Other questions

Does the issue still occur after restarting your computer?

Yes

Have you tried any other versions of NVDA? If so, please report their behaviors.

I have tried a few recent alphas (Oct/Nov, 2023), with the same result.

If NVDA add-ons are disabled, is your problem still occurring?

Yes

Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?

N/A

Activity

  1. bramd commented on Nov 30, 2023

    @bramd
    Contributor

    @XLTechie You indicate that there is a "HumanWare" version, does this mean that your Zoomax is not made by HumanWare? Do you know if it is a USB serial or HID based device? If it is a device with a USB serial interface, you could select the COM port manually and try a few drivers that might work based on the manufacturer.

  2. XLTechie commented on Nov 30, 2023

    @XLTechie
    CollaboratorAuthor
  3. bramd commented on Dec 3, 2023

    @bramd
    Contributor

    @XLTechie Based on BRLTTY sourcecode, this display seems to use the Baum protocol. However, the vendor and product IDs that I see in BRLTTY are not listed in NVDA's Baum driver and therefore will not be autodetected.

    Based on the vendor and product IDs, this seems to be a device with built-in USB serial converter based on the very common CH-340 chip. So, if you choose the Baum driver and manually select the right serial port, this may work.

    To get this autodetected, add it's vendor and product ID to the registerAutomaticDetection method under the KEY_SERIAL key like "VID_1A86&PID_7523",.

    Please let me know if this works.

  4. XLTechie commented on Dec 3, 2023

    @XLTechie
    CollaboratorAuthor

    @bramd many thanks for this research! Will do some tests and report back.

  5. XLTechie commented on Dec 4, 2023

    @XLTechie
    CollaboratorAuthor

    @bramd Unfortunately, it does not. I can select the Baum driver when the display is connected (but not when it isn't). I can choose a comm port--I tried it both in a USB hub and direct, in which case the only port available changed from COM8 to COM7. However both times, I get the no display detected error

    Tried in Alpha and 2023.3.

    I didn't try making a compile with the IDs in auto detection--I figured if it doesn't work manually, it won't work automatically. If I am wrong there, I can try that next.

  6. bramd commented on Dec 4, 2023

    @bramd
    Contributor
  7. added
    p2https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
    triagedHas been triaged, issue is waiting for implementation.
    on Dec 7, 2023
  8. tmthywynn8 commented on Mar 3, 2024

    @tmthywynn8

    I have the same display running version 2.0, firmware 29. I (1) changed the logging level to debug, (2) enabled the hwIo debugging category, (3) restarted NVDA with add-ons disabled, and (4) pressed control+shift+NVDA+f1 to start the log fragment. I then plugged the display into my USB port, pressed ctrl+NVDA+a to choose a braille display, pressed B to choose Baum/HumanWare/APH/Orbit braille displays, tabbed over and chose USB-SERIAL CH340, and pressed Enter. That log fragment is attached (see Zoomax NLS eReader .txt).

  9. bramd commented on Mar 6, 2024

    @bramd
    Contributor

    @tmthywynn8 Thanks for the input. From your log it seems the display doesn't respond at all to the request from the driver. I'm not familiar at all with this hardware, but please ensure it is turned on and set to a braille display mode if it has internal menus or options to do so. Some displays still show up as a serial port, even if the hardware is turned off or otherwise unavailable. A logical next step would be to get this running with BRLTTY to check if that code is working and check the differences between BRLTTY and the NVDA driver.

  10. tmthywynn8 commented on Mar 6, 2024

    @tmthywynn8

    I do not recall if I put the display into USB mode or not, but I did the same steps as earlier, except after plugging it in to the USB port, I made sure to put into USB mode (the display says USB in braille; see ZoomaxNVDA.txt). I will try to use BRLTTY after work.

  11. XLTechie commented on Mar 6, 2024

    @XLTechie
    CollaboratorAuthor
  12. tmthywynn8 commented on Mar 7, 2024

    @tmthywynn8

    So I couldn't get the stand-alone version of BRLTTY to work, however Narrator's interface for it worked like a charm. I couldn't choose USB but had to explicitly choose the serial port (in my case COM5. Once that was done, I started narrator, force-quitted the screen reader, loaded NVDA, and chose BRLTTY as the display. I couldn't type any braille, but panning and other D-keys worked as expected.

    When using BRLTTY with Narrator though, input keys worked as expected, however the space key did not do anything—had to use BL and BR. When I first started Narrator, the display said BRLTTY 5.6 in computer braille (⡃⡗⡇⡞⡞⡿⠀⠢⠨⠖), and when exiting BRLTTY stopped (⡃⡗⡇⡞⡞⠽⠀⠎⠞⠕⠏⠏⠑⠙). If I force-quit Narrator, disconnect and reconnect the uSB cable, the display says BRLTTY 5.6 followed by no screen (⣝⠕⠀⠎⠉⠗⠑⠑⠝). Note that JAWS works without explicitly choosing anything but the display and its connection type, USB.

  13. bramd commented on Mar 10, 2024

    @bramd
    Contributor

    @tmthywynn8 As far as I know, Narrator does not ship with BRLTTY 6.6 and always as an "M" suffix after the version, such as "6.4M". So I think you somehow ran the standalone 6.6 version. By default the standalone version si configured to sleep if the braille API is not used, so that it is just starting when NVDA/Narator accesses it is normal. It would be really helpful if you could give a brltty log with input and output packets logged. You can do this by running debug-brltty.bat from the standalone version. You may need to add the correct parameters for your display such as "-dserial:COM5" to set the port if you don't have that already in brltty.conf. The debug-brltty.bat should log to your terminal and also to a log file if I remember correctly. I hope we ca nsee how BRLTTY initializes the display based on the raw packets and compare this with NVDA.

  14. tmthywynn8 commented on Mar 11, 2024

    @tmthywynn8

    I definitely saw it say "BRLTTY 5.6" and not "6.6M", and yes, the version shipped with Narrator in Windows 10 is 5.6 not 6.6.

    As suggested, I did install the older release instead of the 6.x series, which seemed to work, though input still isn't working with NVDA (I'm probably not doing it correctly). I'm not sure if this is the log you wanted, but I was able to run it with the debug batch file as recommended, though did run it as admin since I saw that the log was going to be written in the program directory. The only change I did was remove the time stamps because it was quite verbose:
    debug.log

  15. tmthywynn8 commented on Mar 21, 2024

    @tmthywynn8

    I received the NLS eReader Zoomax braille display driver from the National Library Service today (see this zip archive), and the display does work with NVDA with both USB and Bluetooth connections. The only problem is that b11 (the spacebar) isn't registered as such in the mapping, though the Bluetooth mode gets around that by mapping it to b10 (identical to BR). Not sure how this is to integrate into the Baum driver, but one of the comments did say it was based on said driver.

  16. seanbudd commented on Apr 29, 2024

    @seanbudd
    Member

    As a priority we should update our documentation to clearly state that this specific device does not work with NVDA.

    Creating support in NVDA for this device will be challenging without spec information from the manufacturer.

  17. bramd commented on May 2, 2024

    @bramd
    Contributor

    @tmthywynn8 Based on that driver the changes seem very minimal. It seems this device does not respond to a cell count request and therefore the Baum driver will not recognize it. In this driver the cell count is hardcoded to 20 cells.

    I think the best solution here would be to find a way to identify this device in the Baum driver and set the cell count to 20 instead of relying on the display reporting it's cell count. Since I don't own this device, I have no easy way to find a good way to identify it and have no motivation to work on this. Besides, I think manufacturers should just extend the driver that is already there and submit their changes to NVDA core to give their users a good user experience. They took the effort to clone the Baum driver and made the minimal changes they need, so doing this properly and submitting a PR to NVDA is not that much of a stretch.

  18. tmthywynn8 commented on May 3, 2024

    @tmthywynn8

    Are you sure? It does look like from the BRLTTY log that the cell count is returned, i.e.:

    serial: input: 1B 01 14
    input packet: 01 14
    Cell Count: 20 (20 text, 0 status)
    

    I will, of course, write to the folks at NLS to see if the author of this driver would be willing to push their code upstream and incorporate into NVDA itself.

  19. bramd commented on May 4, 2024

    @bramd
    Contributor

    @tmthywynn8 Good catch. I was just looking at their driver, which hardcodes the cell count and didn't compare it to the BRLTTY log this time. So I don't know why they do this.

  20. added
    p4https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
    and removed
    p2https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#priority
    on Feb 19, 2025
  21. added this to the 2025.2 milestone on Jun 25, 2025
  22. added a commit that references this issue on Jun 25, 2025
    071247b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    component/braille-display-driversp4https://github.com/nvaccess/nvda/blob/master/projectDocs/issues/triage.md#prioritytriagedHas been triaged, issue is waiting for implementation.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions