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.

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

Braille display auto-detection feature causes errors on loading large braille tables on NVDA startup #9982

Open
DrSooom opened this issue Jul 26, 2019 · 75 comments · May be fixed by #10275

Comments

@DrSooom
Copy link

@DrSooom DrSooom commented Jul 26, 2019

First of all I'm so glad that these errors aren't caused by my HUC Braille Tables alone, because other large braille tables like "zh-tw.ctb" lead to the same results I described in issue #9973 yesterday. CC: @leonardder

Steps to reproduce:

  1. Install/Create a portable copy of NVDA 2019.2 Beta-18176.
  2. Now start NVDA Portable and change the braille output table to Chinese Taiwan/Mandarin ("zh-tw.ctb") and disable the checkbox "Expand to computer braille for the word at the cursor".
  3. Restart NVDA with debug logging level via NVDA+Q.

Actual behavior:

This time I was able to reproduce both errors I mentioned in issue #9973 on a SSD, but I couldn't figure out if the Chinese braille table "zh-tw.ctb" (of course without the HUC Braille Tables) was completely loaded or not. Maybe you have to restart NVDA multiple times to get these errors.

Here is the first logfile with no error sound on startup. And here is the second one with an error sound and no braille output directly after startup. Always start at line 126. And please take a look at the timestamps in the second logfile, because there aren't any log entries from the beginning of the error sound until the Protocol Viewer was opened. That's so strange, therefore I repeated restarting NVDA in Debug Mode multiple times, because I thought I did something wrong. Normally NVDA should also have logged pressing ArrowRight and ArrowLeft in the Windows Explorer (Detail View) as well as the steps to open the Protocol Viewer via the NVDA menu. But that was never the case.

Expected behavior:

No errors on loading large braille tables.

  • zh-tw.ctb: 1,25 MB (1,306,176 Bytes); 48,769 lines

System configuration

NVDA installed/portable/running from source:

Portable

NVDA version:

2019.2 Beta-18176

Windows version:

Win7x64

Other information about your system:

Optelec ALVA BC680 is connected via USB2. The USB1 port wasn't tested.

Other questions

Does the issue still occur after restarting your PC?

Not tested.

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

Tests with 2019.1.1 (Portable) are pending. But I guess it's the same behavior like in issue #9973 – it works as expected. And smaller braille tables such as the Finish 8-dot Computer Braille ("fi-fi-8dot.ctb") seems to work with NVDA 2019.2 Beta-18176 as expected too. But deeper tests are pending here too.

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Jul 26, 2019

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Jul 26, 2019

That were/are always fresh portable Betas of NVDA. NVDA 2018.1 is installed on my system. Here is my config file. I guess it's a regression. Furthermore you can't compare these Betas with the Py3-Alphas because of PR #9544 and #9545.

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Jul 26, 2019

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Jul 27, 2019

Do you have reasons to think that this is a bug in NVDA and not in liblouis?

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Jul 27, 2019

@leonardder: You ask me things? That could be also caused by the Liblouis update from 3.8.0 to 3.10.0 over 3.9.0. This issue didn't occur in NVDA 2019.1.1 with Liblouis 3.8.0.

Therefore: CC: @bertfrees, @egli, @dkager and @nishimotz (if you are using Liblouis).

@lukaszgo1

This comment has been minimized.

Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Jul 28, 2019

@DrSooom Could you please test this with the last Python 2 Alpha of NVDA available here. I am asking because in issue #9486 the errors are similar, and it is caused by liblouis builds being optimized. If my hypothesis would be correct perhaps disabling optimization for liblouis builds for the time being would be reasonable. @leonardder What do you think?

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Jul 28, 2019

NVDA Alpha-18064 logfile on loading "zh-tw.ctb" after NVDA restart in Debug Mode:

Initializing global plugin handler
DEBUGWARNING - braille.BrailleHandler.setDisplayByName (20:39:28.825):
Error in initial display after display load
Traceback (most recent call last):
  File "braille.pyc", line 1686, in setDisplayByName
  File "braille.pyc", line 1976, in initialDisplay
  File "braille.pyc", line 1840, in handleGainFocus
  File "braille.pyc", line 1845, in _doNewObject
  File "braille.pyc", line 1516, in getFocusRegions
  File "braille.pyc", line 615, in update
  File "braille.pyc", line 428, in update
  File "louisHelper.pyc", line 65, in translate
  File "louis\__init__.pyc", line 183, in translate
WindowsError: exception: access violation reading 0x08DF7608
IO - braille.BrailleBuffer.update (20:39:29.046):
Braille regions text: [u'NVDA ist bereit']
IO - braille.BrailleHandler.update (20:39:29.046):
Braille window dots: 13457 12367 1457 17 - 24 234 2345 - 12 15 1235 15 24 2345
DEBUG - core.main (20:39:29.048):
Initializing core pump

And here is the complete logfile (start at line 149) after NVDA Alpha-18064 (Portable on a SSD) totally crashed after a few more restarts in Debug Mode. Only the Windows Explorer was opened during these tests. The HUC Braille Tables weren't tested.

@Andre9642

This comment has been minimized.

Copy link
Contributor

@Andre9642 Andre9642 commented Jul 29, 2019

Hi,
I've just tested and I wasn't able reproduce this bug. Tested with 2019rc1 and alpha-18222,be63d19d (portable versions). I Restarted NVDA about 10 times.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Jul 29, 2019

@Andre9642: Regarding NVDA 2019.2 RC1 I can confirm this. I also didn't get any errors. I wonder why. Therefore: Closing for now.

@DrSooom DrSooom closed this Jul 29, 2019
@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Aug 8, 2019

This issue is back in NVDA 2019.2 RC2 (portable). Here is the logfile with "zh-tw.ctb" and freezing on startup (which wasn't logged, because I was able to kill the process "nvda.exe" via the Task Manager). The HUC Braille Tables are also affected.

@DrSooom DrSooom reopened this Aug 8, 2019
@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Aug 9, 2019

A nice new log entry with NVDA 2019.2 Beta-18345 on startup. Complete logfile

RuntimeError: Can't translate: tables [u'louis\tables\zh-tw.ctb', 'braille-patterns.cti'], inbuf N V D A i s t b e r e i t , typeform None, cursorPos c_long(0), mode 4

Note: There is a strange character between the letters in the logfile, It's not a space (U+0020) – maybe CR, LF or CRLF together.
CC: @leonardder, @zstanecic, @bertfrees and @egli

@DrSooom DrSooom changed the title Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176 Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 Aug 9, 2019
@Adriani90

This comment has been minimized.

Copy link
Collaborator

@Adriani90 Adriani90 commented Aug 14, 2019

@DrSooom are you able to reproduce this in NVDA 2019.2 final release?

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Aug 15, 2019

Sadly absolutely no differences with NVDA 2019.2 Stable (Portable). Tested multiple times on a SSD and on a USB Flash Drive. Issue #9973 as well as this one here are still valid.

Question: Why did this all work as expected in NVDA 2019.2 RC1? What changes have been made since 2019.2 RC1 to 2019.2 Stable regarding liblouis? The file "zh-tw.ctb" wasn't changed (I checked the SHA-256 sums).

And here follows the significant part of the logfile (HUC8 Braille Tables were included into "de-de-comp8.ctb", but it's the same with "zh-tw.ctb" alone):

Initializing global plugin handler
IO - braille.BrailleBuffer.update (12:51:58.680):
Braille regions text: [u'Desktop fst']
ERROR - core.main (12:51:59.104):
Traceback (most recent call last):
  File "core.pyo", line 461, in main
  File "braille.pyo", line 1799, in message
  File "braille.pyo", line 428, in update
  File "louisHelper.pyo", line 65, in translate
  File "louis\__init__.pyo", line 183, in translate
WindowsError: exception: access violation writing 0x00000000
DEBUG - core.main (12:51:59.104):
Initializing core pump
@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Aug 16, 2019

Question: Why did this all work as expected in NVDA 2019.2 RC1? What changes have been made since 2019.2 RC1 to 2019.2 Stable regarding liblouis

Nothing has changed in the braille area as far as I'm aware, except for the fact that all dll's (including liblouis) have been recompiled.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Aug 16, 2019

Here is the logfile based on NVDA 2019.2 Portable running from a USB 3.0 Flash Drive (connected via USB 2.0). This time several Unicode characters in the Basic Latin block (U+0000 to U+007F) weren't loaded correctly. See line 181 to 194.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Aug 18, 2019

Same result on startup with NVDA 2019.2.1 Beta-18416 (Portable, release date: 2019-08-15) as I described here. Personally I would give this issue here a P2, as it is critical for Chinese users – and maybe others too.

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Aug 19, 2019

This definitely looks like a liblouis issue to me, therefore I'd like to suggest opening an issue against liblouis as well.

Just to make sure, does this problem also occur with NVDA 2019.1?

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Aug 19, 2019

@feerrenrut I think we should consider reverting the update to liblouis 3.10, i.e. go back to liblouis 3.9 and see what that does here.

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Aug 19, 2019

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Aug 19, 2019

@lukaszgo1

This comment has been minimized.

Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Sep 24, 2019

@DrSooom I have tried to reproduce it with portable version of NVDA 2019.2 placed on my data partition, under Windows 7 without success.
To make sure that it isn't something specific to your NVDA config I've even copied your config file - still no error.
Things that are different:

  1. Language of Windows - mine is in Polish.
  2. Braille display in use _ I've tried with Focus 40 blue 4th gen. I don't have access to Alva, and probably you don't have access to any other display either.

Are there any other differencess that you can think of?

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Sep 25, 2019

@DrSooom Could you please test with this try build

If this build doesn't have the issue for you, I will make #10275 close this issue.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 25, 2019

Here is the Stand-PC (win7x64, 6 GB RAM, SSD) logfile for NVDA 2019.2.1 Try-18768 Portable and here the used "nvda.ini" file (please delete the txt file extension).

  • Line 94 to 98: ALVA driver permission error; not new. See the section "Additional information regarding the Optelec ALVA BC680" in issue #9973. This issue also occurs on my NUC, where NVDA 2015.3 is installed without any additional braille drivers in the "brailleDisplayDrivers" folder in the NVDA configuration folder.
  • Line 167 to 178: "noback" and "context" opcode errors.
  • Line 179 to 189: No changes here in compare to NVDA 2019.2.1 Try-RC1-18694.
  • Line 197 to 200: Nice info. It explains why there isn't a braille output directly after NVDA started – the braille tables couldn't be compiled.
  • Line 201 to 213: The kind how the Unicode characters are logged for this runtime error is different to my previous logfiles.
  • Line 222 to 237: Braille tables are loaded again, but maybe just parts of them.

And here is the logfile from my NUC (also win7x64, 8 GB RAM, SSD). The line 162 says that the include opcode isn't defined, which is really odd.

@dingpengyu

This comment has been minimized.

Copy link
Contributor

@dingpengyu dingpengyu commented Sep 25, 2019

Here is the Stand-PC (win7x64, 6 GB RAM, SSD) logfile for NVDA 2019.2.1 Try-18768 Portable and here the used "nvda.ini" file (please delete the txt file extension).

  • Line 94 to 98: ALVA driver permission error; not new. See the section "Additional information regarding the Optelec ALVA BC680" in issue #9973. This issue also occurs on my NUC, where NVDA 2015.3 is installed without any additional braille drivers in the "brailleDisplayDrivers" folder in the NVDA configuration folder.
  • Line 167 to 178: "noback" and "context" opcode errors.
  • Line 179 to 189: No changes here in compare to NVDA 2019.2.1 Try-RC1-18694.
  • Line 197 to 200: Nice info. It explains why there isn't a braille output directly after NVDA started – the braille tables couldn't be compiled.
  • Line 201 to 213: The kind how the Unicode characters are logged for this runtime error is different to my previous logfiles.
  • Line 222 to 237: Braille tables are loaded again, but maybe just parts of them.

And here is the logfile from my NUC (also win7x64, 8 GB RAM, SSD). The line 162 says that the include opcode isn't defined, which is really odd.

hi DrSooom
Can you use windows10 to do the above tests?

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 25, 2019

Sadly no, because there isn't any physical machine running Windows 10 yet. And I haven't set up a VM for it too.

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Sep 25, 2019

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Sep 25, 2019

@DrSooom: Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

Note, NVDA Try-18768 is a version in the 2019.3 range, not based on 2019.2.1. For ease of understanding, it would be best to refer to the name of the try build (i.e. try-liblouis3.11withClangOnVS2019 in this case).

@lukaszgo1

This comment has been minimized.

Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Sep 25, 2019

@DrSooom in #8106 you've mentioned that you have Baum braille display. Would you be able to test with it? Given the fact that no one except you is able to reproduce it is must be something specific to your two pc's.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 25, 2019

Are you saying that you have the Chinese table loading error on this build? That would be a regression from current alpha snapshots, right?

I never tested Py3-Alpha builds. But others said that "zh-tw.ctb" loaded correctly. I'm not sure if everybody immediately looked into the Log Viewer after starting NVDA. During a quick test, it seems that this braille table is loaded correctly with NVDA 2019.2.1 Beta 1 again. But this doesn't say anything. As the HUC Braille Tables still raise that error, I just think that the total file size level has changed again.

@lukaszgo1: Yes, I own a BAUM SuperVario2 64, which got broken by an Austrian braille dealer during cleaning. More details about the still open case can be read on my website. Personally I don't intent to touch it until this case is finally closed. I had a huge luck to find a second-hand Optelec ALVA BC680 via a C2C purchase, as there is only one company in whole Austria, which sells, repairs and cleans braille displays. But repairing this specific braille display is no longer possible because "the tree" (BAUM Retec AG, manufacture) has died in October 2017. And KSG does no longer sell SC9 braille modules. Sadly there is more broken on that BAUM braille device than only 40 of 64 braille modules due to that cleaning process by the Austrian company.

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Sep 25, 2019

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Sep 25, 2019

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 25, 2019

File name: usb-cert-baum.zip (removed on 2019-10-26)
File size: 1.54 MB (1,615,480 Bytes)
SHA-256: 281947b58571f5d371a15415ae6a5afbbc002bf029adfa4fb5b9f6f38cc93e5b

I've temporarily uploaded the BAUM braille display driver (version V7 02/17/2009 2.04.16) onto my webserver, which was released in January 2010 (based on the date of the Installer). Perhaps this driver influences the NVDA-own ALVA driver and/or the braille display auto-detection feature in NVDA. This driver package is installed on both machines – Stand-PC and NUC. But as I wrote before: the broken BAUM SuperVario2 64 isn't connected to these machines.

@zstanecic: Which OS?

@zstanecic

This comment has been minimized.

Copy link
Contributor

@zstanecic zstanecic commented Sep 25, 2019

@lukaszgo1

This comment has been minimized.

Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Sep 25, 2019

@DrSooom Two more things:

  1. Could you please compress, and upload somewhere the entire folder in which portable NVDA is placed?
  2. I have a feeling that presence of older NVDA versions on your pcs might have something to do with this problem. Could you disable autostarting of whatever version is installed, reboot your machine, start the portable build either blindly or with Narrator without running installed NVDA and try to reproduce this?
@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 25, 2019

  1. 9982_NVDA_2019.3 Try-18768.7z (22.0 MB, temp. available, removed on 2019-10-26)
  2. Do you also mean the logon screen? Or shall I set up a new Win7 VM, which I could do in the upcoming days?
@lukaszgo1

This comment has been minimized.

Copy link
Contributor

@lukaszgo1 lukaszgo1 commented Sep 25, 2019

I would start with disabling from both autostart, and logon screen, and if it still would be reproducible then go to the more time consuming process of creating a VM.

@school510587

This comment has been minimized.

Copy link

@school510587 school510587 commented Sep 26, 2019

Hi all,

I'm a zh_TW user with Windows version 6.1.7601 service pack 1 (64-bit). I have tested both 2019.2 and alpha-18759,6cb40529 NVDA versions, and no problem occurred during zh_TW loading.

Also, I am the current maintainer of zh-tw.ctb, but no other Taiwanese user reported similar bug to me. I thus don't know existence of this issue.

@DrSooom DrSooom changed the title Errors on loading large (Chinese) braille tables with NVDA 2019.2 Beta-18176, 2019.2 Beta-18345 and 2019.2 RC2 Auto-Detection of an Optelec ALVA BC680 causes errors on loading large braille tables on NVDA startup Sep 26, 2019
@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 26, 2019

EUREKA! I got it!

Now I know why nobody without an Optelec ALVA BC680 was able to reproduce this issue. No, it isn't caused by any braille tables – also not by my HUC Braille Tables. And I guess that it isn't caused by Liblouis too.

The kind how NVDA is started on the logon screen has changed between NVDA 2015.3 and 2015.4. And the ALVA driver has changed between NVDA 2017.4 and 2018.1. On my Stand-PC NVDA 2018.1 is installed and on my NUC 2015.3. But the symptoms are/were exactly the same on both machines with NVDA Try-18768 (Py3, will get to 2019.3).

And now: The braille display auto-detection feature was added to NVDA 2018.3 and didn't exist before. And exactly this feature in combination with a connected Optelec ALVA BC680 via USB1 or USB2 (this braille display has two USB ports) is responsible for the loading errors of Liblouis braille tables – and nothing else.

I tested the largest Liblouis braille table "zh-tw.ctb" and the HUC8 and the HUC6 Braille Tables (included into "de-de-comp8.ctb" and "de-g1.ctb" and stand-alone) multiple times with NVDA 2019.2.1 Beta 1 Portable (Liblouis 3.10.0) and NVDA Try-18768 Portable (Liblouis 3.11.0) on my Stand-PC. I also successfully tested the UTF32 files of the HUC Braille Tables with NVDA Try-18768. Okay, the more braille tables are included, the longer NVDA requires to start. If only "huc8-u+0000-u+ffff.tbi" and "huc8-u+10000-u+1ffff.tbi" are included, no lag on startup is recognizable. After including "huc8-u+20000-u+2ffff.tbi" as well, NVDA requires around four seconds to be fully started. Well, and the more braille tables are included, the longer it takes. But this isn't really relevant yet, because there are just 337 allocated Unicode characters in the Unicode planes 3 to 16 in the Unicode Standard 12.1 (may 2019).

In all testing scenarios I was immediately able to force this issue after I switched back from "Optelec ALVA 6-Serien/Protokoll-Konverter" ("display = alva") to "Automatisch (Optelec ALVA 6-Serien/Protokoll-Konverter)" ("display = auto" in the "nvda.ini") in the Braille NVDA Settings. If the braille display was chosen directly from the list of braille displays, these loading errors don't occur – on a SSD. Therefore I changed the issue title. If wanted, I also can test this by running NVDA Portable from an USB 3.0 flash drive as well as on my NUC (SSD).

@leonardder: Please let me know if you need a logfile with enabled HWIO logging for fixing the braille display auto-detection feature.

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Sep 26, 2019

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 26, 2019

Here are five logfiles. "p13" is from Try-18768 and the other four from Alpha-18783. The very last line in "p13" is extremely strange, as there aren't any absolute paths in the HUC Braille Tables. As this loaded process took too much time, I launched NVDA 2018.1 via the desktop shortcut – if I memorize correctly. (There were too many tests in the last 4.5 hours. 😉)

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Sep 27, 2019

Yes, pretty sure it is as described in #9982 (comment)

I will look into the code and will provide a try build shortly.

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Sep 27, 2019

I'm pretty sure try build try-initialDisplayFix will fix the issues you're having.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Sep 27, 2019

Here are ten new logfiles. I'm confused. I'm not sure if this issue is really completely solved by Try-18797, but the braille tables seems to be fully loaded on NVDA startup – excluding the "p19" log, which I couldn't reproduce again during testing. Thus "p19" only occurred once. I tested all the same braille tables, which I tested yesterday on, a SSD again. Tests on a USB 3.0 flash drive are still pending.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Oct 1, 2019

@leonardder: Shall I test Try-18797 right now on a USB flash drive too or are you going to provide a new Try-build?

@leonardder

This comment has been minimized.

Copy link
Collaborator

@leonardder leonardder commented Oct 2, 2019

@leonardder: Shall I test Try-18797 right now on a USB flash drive too or are you going to provide a new Try-build?

Yes, please. I don't have any starting points to change anything in the current try build.

@DrSooom

This comment has been minimized.

Copy link
Author

@DrSooom DrSooom commented Oct 2, 2019

Done. NVDA Try-18797 Portable works exactly the same on a USB 3.0 flash drive (connected via a USB 3.0 and a 2.0 port) like on an internal SSD.

NVDA 2019.2.1 still has this issue if the HUC Braille Tables are used. But it seems that "zh-tw.ctb" is completely loaded on startup again – I got no errors in the logfiles when using the auto-detection feature. Otherwise: Not using the braille display auto-detection feature also solves the loading error with the HUC braille Tables, as I already mentioned last Thursday. Thus this finding is also valid for NVDA 2019.2.1.

@DrSooom DrSooom changed the title Auto-Detection of an Optelec ALVA BC680 causes errors on loading large braille tables on NVDA startup Braille display auto-detection feature causes errors on loading large braille tables on NVDA startup Oct 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.