Attachment nvda-braille-error.log added by mwhapples on 2012-01-07 22:46
Description:
Log showing an occasion when Braille freezes. The freeze happened in the run dialog where I typed c:\eclipse\eclipse, the next action was to return to the desktop and press NVDA+f1 for the log viewer.

Comment 1 by mwhapples on 2012-01-07 22:49
I have looked at the attached log file, I cannot spot anything in the log file to indicate that Braille froze, so unless anyone else can spot somthing in the log file then I will need to do something else to find the source of the issue. Any suggestions on what I should do to find the source of the issue?

Comment 2 by jteh on 2012-01-09 07:45
When this occurs, try setting NVDA to no braille and then opening a command prompt. Does your braille display change? BRLTTY should read console applications by itself. If it doesn't, BRLTTY isn't functioning properly for some reason, in which case the issue is not with NVDA.

Comment 3 by mwhapples (in reply to comment 2) on 2012-01-09 13:55
To clarify what I wrote below, "frm time to time" I mean the random dots may vary on different starts of BrlTTY, the dots stay the same for a given execution of BrlTTY.
Replying to jteh:

When this occurs, try setting NVDA to no braille and then opening a command prompt. Does your braille display change? BRLTTY should read console applications by itself. If it doesn't, BRLTTY isn't functioning properly for some reason, in which case the issue is not with NVDA.

Even when BrlTTY is functioning correctly with NVDA on this windows7 system it does not seem to read console windows by itself (starting command prompt by going to run and typing cmd ).

There are two things I would like to note though at this point: Firstly when BrlTTY starts normally on my system as it is set as a service, after the initial BrlTTY message disappears a load of rubbish is shown on the Braille display (rubbish as it seems to be a random combination of dots and can vary from time to time). Initially I thought this may be an issue relating to NVDA starting sooner than BrlTTY at the log on screen, however I disabled NVDA starting at the log on screen and still the rubbish appears on the Braille display until I log in and start NVDA. The second point is that as I suspected something odd is going on with this rubbish being shown on my braille display initially (and the rubbish being restored if I exit NVDA) I thought may be thi were affecting BrlTTY in accessing the console window, so I got BrlTTY to be restarted on my system (so it shows the normal "no foreground window" message) but BrlTTY is still unable to access the console window on its own.

Is BrlTTY able to access console windows on a 64-bit system?

Comment 4 by orcauser on 2012-01-09 14:28
I also see the "rubbish" that you mension in linux,
when braille is enabled in orca, but orca was started before brltty. Restarting Orca fixes the problem in the linux case.

Do you still get no interaction in the terminal even after switching to no braille in nvda?
Dont have a 64 windows system, so cant personally test.

Comment 5 by mwhapples (in reply to comment 4) on 2012-01-09 16:03
Replying to orcauser:

I also see the "rubbish" that you mension in linux,

when braille is enabled in orca, but orca was started before brltty. Restarting Orca fixes the problem in the linux case.

Do you still get no interaction in the terminal even after switching to no braille in nvda?

That is correct, BrlTTY does not access the console even when NVDA Braille is set to none or if I exit NVDA and open a command prompt.

I have posted about this issue to the BrlTTY mailing list to see if its a BrlTTY issue, I will also possibly try some other versions of BrlTTY.

Dont have a 64 windows system, so cant personally test.

Comment 6 by mwhapples (in reply to comment 5) on 2012-01-09 17:25
For what it is worth, I have tried BrlTTY 4.2-3 and have observed Braille Freezing like I have describe here already for BrlTTY 4.3-2.
Replying to mwhapples:

Replying to orcauser:

I also see the "rubbish" that you mension in linux,

when braille is enabled in orca, but orca was started before brltty. Restarting Orca fixes the problem in the linux case.

Do you still get no interaction in the terminal even after switching to no braille in nvda?

That is correct, BrlTTY does not access the console even when NVDA Braille is set to none or if I exit NVDA and open a command prompt.

I have posted about this issue to the BrlTTY mailing list to see if its a BrlTTY issue, I will also possibly try some other versions of BrlTTY.

Dont have a 64 windows system, so cant personally test.

Comment 7 by mwhapples on 2012-01-10 22:24
I have asked about this on the BrlTTY mailing list, it appears it may be an issue with BrlTTY or libusb. As BrlTTY is the way the vast majority of Braille displays are supported by NVDA, I don't know whether you want to keep this ticket open until the issue is fixed with the other software or whether you simply want to close this ticket as it is not a trouble with NVDA.

Comment 8 by jteh on 2012-01-10 23:09
Leaving open so we can track this. Please update with any further info.

Comment 9 by mwhapples (in reply to comment 8) on 2012-01-15 18:56
Hello,
An update on what I have found out. I suspected for some reason that may be the issue was related to the cursor blinking and so potentially too much being asked of the Braille display at a given time. While I am not fully sure if my reasoning is sound, I decided to set the cursor blink rate to 0 in NVDA and this up to this point seems to have solved the issue for me.

I have only been trying this for a couple of hours, however Braille has not frozen yet. While it looks promising I don't want to commit to saying that this certainly has fixed it until I have observed no freeze for a couple of days of use.

If this does fix the issue then is there anything NVDA can do or would you suggest still taking this extra information to BrlTTY developers?
Replying to jteh:

Leaving open so we can track this. Please update with any further info.

Comment 10 by jteh on 2012-01-15 22:01
I'd still suggest taking this to the BRLTTY devs. As far as NVDA is concerned, it is just sending new cells to the display every time the cursor blinks. Cursor blinking is not special in terms of what we call with BRLAPI.

It's worth noting that we only write raw dots to the display; i.e. we don't use BRLAPI's own cursor position functionality. Also, at this point, we always send an entire display length full of text; i.e. we never just update one cell, even if only one cell changed. I can't remember whether BRLAPI even allows you to update a region, but I know that BRLTTY itself does, so this may be important info.

Comment 11 by mwhapples (in reply to comment 10) on 2012-01-15 23:14
It seems to not have totally solved the issue anyway, I have had a couple of freezes of Braille since my last comment.

As it does seem to have slightly improved things (I haven't yet encountered a freeze while typing which was my most likely way of causing a freeze before) it may be worth me mentioning turning off the cursor blink in NVDA. Can I just check whether the cursor blinking is in a separate thread or not to the rest of the Braille output (IE. could there be cases where my system is giving BrlTTY two simultaneous Braille output calls).
Replying to jteh:

I'd still suggest taking this to the BRLTTY devs. As far as NVDA is concerned, it is just sending new cells to the display every time the cursor blinks. Cursor blinking is not special in terms of what we call with BRLAPI.

It's worth noting that we only write raw dots to the display; i.e. we don't use BRLAPI's own cursor position functionality. Also, at this point, we always send an entire display length full of text; i.e. we never just update one cell, even if only one cell changed. I can't remember whether BRLAPI even allows you to update a region, but I know that BRLTTY itself does, so this may be important info.

Comment 12 by jteh on 2012-01-15 23:26
No, cursor blinking is in NVDA's main thread, as is all other braille output. It is handled using a wx timer.

Comment 13 by mwhapples on 2012-01-18 01:20
The cause of the problem still seems to be hidden, I have other troubles with this Alva on Windows7 with BrlTTY causing a crash as well.

I decided to do a little bit of looking at using the official Alva drivers (there is an SDK on the openbraille website) and well I could get python talking to the display via Alva's drivers. Would it be worth me looking into creating a driver for NVDA using the official Alva drivers? I found ticket#447 which was along that line, however nothing was done on it for a long time, therefore I would like to know if there were reasons why it never happened and if those reasons will cause problems for me.

Comment 14 by mwhapples on 2012-02-10 11:32
Just a further comment. The problem is supposedly in libusb in BrlTTY, so affects the ALVA when using USB for the connection. I have for the time solved the issue by getting a USB to serial adapter and connecting the ALVA by serial. In my case this is reasonably satisfactory as its a desktop system and so always has a power supply, may not be so satisfactory for laptop users as they need a power supply for the Braille display (NOTE in such a case one could use a USB connection to power the display from the computer and the serial cable for communication, that is how I used the ALVA when I first used Linux when BrlTTY did not support USB connections for the ALVA).

Various comments on this ticket by the original author indicate that this issue lies with the Braille display and not NVDA itself. Given that this issue is more than five years old, unless our resident Braille experts recommend otherwise, I suggest closing. @ehollig

@ehollig what do you suggest?

Thank you for finding this issue @Adriani90. I should have closed this issue months ago. Closing as invalid