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

Error in Freedom Scientific focus braille detection after standby/resume of PC #9830

Closed
MarcoZehe opened this issue Jun 27, 2019 · 18 comments · Fixed by #13330
Closed

Error in Freedom Scientific focus braille detection after standby/resume of PC #9830

MarcoZehe opened this issue Jun 27, 2019 · 18 comments · Fixed by #13330
Milestone

Comments

@MarcoZehe
Copy link
Contributor

Steps to reproduce:

  1. Connect a Freedom Scientific braille display.
  2. Send PC to standby.
  3. After a while, reopen lid or wake PC up. Windows will come up with a login prompt or such to enter a PIN (in my case). NVDA's default logon screen version detects the focus.
  4. Log in.
  5. Braille display updates with info of last opened app.
  6. After one or two focus changes, the display stops updating, and after a moment, the Windows "USB device disconnected" sound is heard, followed by the reconnect sound.
  7. At the same time, an NVDA error sound is heard, and right after that, the display starts working as normal. The error log is:

ERROR - braille.executor (14:02:22.349):
Error displaying cells. Disabling display
Traceback (most recent call last):
File "braille.pyc", line 2085, in executor
File "brailleDisplayDrivers\freedomScientific.pyc", line 474, in display
File "brailleDisplayDrivers\freedomScientific.pyc", line 279, in _sendPacket
File "hwIo.pyc", line 101, in write
WindowsError: [Error 22] Das Gerät erkennt den Befehl nicht.
ERROR - braille.BrailleHandler.handleDisplayUnavailable (14:02:22.380):
Braille display unavailable. Disabling
Traceback (most recent call last):
File "braille.pyc", line 2085, in executor
File "brailleDisplayDrivers\freedomScientific.pyc", line 474, in display
File "brailleDisplayDrivers\freedomScientific.pyc", line 279, in _sendPacket
File "hwIo.pyc", line 101, in write
WindowsError: [Error 22] Das Gerät erkennt den Befehl nicht.
DEBUG - braille.BrailleHandler.setDisplayByName (14:02:22.407):
Switching braille display from freedomScientific to noBraille
INFO - braille.BrailleHandler.setDisplayByName (14:02:22.411):
Loaded braille display driver noBraille, current display has 0 cells.
DEBUG - brailleDisplayDrivers.freedomScientific.BrailleDisplayDriver._onReceive (14:02:22.423):
Got packet of type '\x01' with args: '\x00' '\x00' '\x00'
DEBUG - brailleDisplayDrivers.freedomScientific.BrailleDisplayDriver._onReceive (14:02:22.424):
Got packet of type '\x80' with args: '0' '\x00' '\x00'
DEBUG - brailleDisplayDrivers.freedomScientific.BrailleDisplayDriver._handlePacket (14:02:22.424):
Device info: manufacturer: FREEDOM SCIENTIFIC model: Focus 40, version: 5.81-34
INFO - brailleDisplayDrivers.freedomScientific.BrailleDisplayDriver.init (14:02:22.424):
Found Focus 40 connected via custom (\?\usb#vid_0f4e&pid_0114#1234567#{a5dcbf10-6530-11d2-901f-00c04fb951ed})
DEBUG - brailleDisplayDrivers.freedomScientific.BrailleDisplayDriver._configureDisplay (14:02:22.424):
Activating extended keys on freedom Scientific display. Display name: Focus 40, firmware version: 5.81-34.
DEBUG - braille.BrailleHandler.setDisplayByName (14:02:22.424):
Switching braille display from noBraille to freedomScientific
INFO - braille.BrailleHandler.setDisplayByName (14:02:22.428):
Loaded braille display driver freedomScientific, current display has 40 cells.

Actual behavior:

See step 7 above. Interruption in braille display service.

Expected behavior:

No interruption.

System configuration

NVDA installed/portable/running from source:

Installed.

NVDA version:

version alpha-17832,7dd122b7

Windows version:

19h1.

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

Freedom Scientific Focus 40 Blue 5th Generation with latest USB driver from FS.

Other information about your system:

Dell XPS15--9560.

Other questions

Does the issue still occur after restarting your PC?

No, does not happen when initially logging in, only when waking up from standby.

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

19.2beta2, same result. Earlier versions don't have the native driver from #7727 yet.

CC @bramd

@bramd
Copy link
Contributor

bramd commented Jun 27, 2019

@MarcoZehe Thanks for the issue report. I'll try to reproduce this.

Braille handling between the NVDA version that runs on the sign in screen and the normal version is still a bit of a mess. NVDA doesn't explicitly close/free the display when you switch versions, so often braille doesn't even work on secure screens. It might be that the Freedom Scientific driver allows two applications to open it at once and the display gets messages from both leading to a disconnect or firmware crash.

@LeonarddeR
Copy link
Collaborator

Hmm, the two file handles that are used for Bulk communication are opened in exclusive mode. Therefore, it slightly amazes me that your system is able to pick up the Focus at the login prompt while there is a connection with the NVDA that's running under your user account.

Could you please describe the behavior when:

  1. From a running desktop, you press ctrl+alt+del? Is the display picked up in that case? What happens if you switch back?
  2. Set the default braille display to no braille, save your configuration and copy it to the system configuration. After that, NVDA shouldn't not communicate with the Focus at the logon screen. How is the behavior when you're coming out of stand by in that case?

@MarcoZehe
Copy link
Contributor Author

  1. After pressing CTRL+Alt+Del, the braille display comes up, with the English braille table and other indicators that the factory profile is now active. My standard in my user config is German.
  2. If I escape out of this, the display briefly winks out, then comes back with German braille. And no errors, handoff seems to work fine between these two.
  3. If choosing the Lock link after pressing CTRL+Alt+Del, and then unlocking the machine again, handoff also works fine.

Should I still try to set to NoBraille and such? Because it seems that this scenario I observe only applies to the moment when the machine returns from standby, meaning a real deep sleep. Normal handoff between these scenarios seems to work fine.

@MarcoZehe
Copy link
Contributor Author

Interestingly, on my second machine, which has a Handy Tech ActiLino connected, which also uses auto detection, when in the lock screen, the display is not active. It is only active when logged in.

@DrSooom
Copy link

DrSooom commented Jun 29, 2019

@MarcoZehe: Please compare the braille settings between both nvda.ini (userConfig and systemConfig) by opening them in Notepad++. The userConfig is located in AppData\Roaming\nvda and the systemConfig in the program folder where NVDA was installed.

@MarcoZehe
Copy link
Contributor Author

Sorry it took me a while to get back to this. I still see this behavior in the latest alpha builds.

There is no nvda.ini in the program Files (x86)\NVDA folder, I only have one nvda.ini in my AppData/Roaming/nvda folder. I also don't remember ever consciously having removed the one from the Program Files folder.

@DrSooom
Copy link

DrSooom commented Aug 5, 2019

@MarcoZehe: I meant the "nvda.ini" in the folder "C:\Program Files (x86)\NVDA\systemConfig". This folder stores the configuration for the logon/secure screen.

@MarcoZehe
Copy link
Contributor Author

There's no nvda.ini there, either. Only an addonstate.picle file.

@DrSooom
Copy link

DrSooom commented Aug 5, 2019

@MarcoZehe: If NVDA is installed, please press the button "Use currently saved settings on the logon and other secure screens (requires administrator privileges)" in the General NVDA Settings and then reboot the PC.

@LeonarddeR
Copy link
Collaborator

I have a customer with a 4th generation focus 80 , firmware 5.7.1 who seems to suffer from the same issue.

@jcsteh: Could you reproduce this with your Focus 5th gen?

@jcsteh
Copy link
Contributor

jcsteh commented Aug 8, 2019

I can't reproduce this here with my 5th gen. However, I too see output from the secure desktop copy of NVDA (e.g. when I press control+alt+delete), so apparently, exclusive mode is not so exclusive with this driver. Also:

  1. In the main copy of NVDA, open the Python console.
  2. Enter this command:
    wx.CallLater(5000, lambda: braille.handler.message("hi"))
  3. Quickly and immediately press control+alt+delete.
    • Observe: When the control+alt_+delete screen comes up, you will see its output on the braille display.
  4. Wait a few seconds.
    • Observe: "hi" appears on the display.
  5. Press tab.
    • Observe: The next control focused in the control+alt+delete screen is reported on the display.
  6. Wait a few more seconds (until the "hi" message expires).
    • Observe: "secure Desktop" appears on the display.

So it seems the display quite happily takes interspersed output from both copies. It doesn't seem to cause a driver crash on my system, but it's certainly conceivable that there is a race condition at play here.

@LeonarddeR
Copy link
Collaborator

LeonarddeR commented Aug 9, 2019 via email

@jcsteh
Copy link
Contributor

jcsteh commented Aug 9, 2019

>>> list(bdDetect.getConnectedUsbDevicesForDriver("freedomScientific"))
[DeviceMatch(type='custom', id='VID_0F4E&PID_0114', port='\\\\?\\usb#vid_0f4e&pid_0114#1234567#{a5dcbf10-6530-11d2-901f-00c04fb951ed}', deviceInfo={'hardwareID': 'USB\\VID_0F4E&PID_0114&REV_0581', 'usbID': 'VID_0F4E&PID_0114', 'devicePath': '\\\\?\\usb#vid_0f4e&pid_0114#1234567#{a5dcbf10-6530-11d2-901f-00c04fb951ed}'})]

So only 1 match.

@Adriani90
Copy link
Collaborator

cc: @bramd

@Adriani90
Copy link
Collaborator

@MarcoZehe I guess you are still having this issue in NVDA 2020.1 Is this correct?

@MarcoZehe
Copy link
Contributor Author

Correct, still happening.

@krzysz00
Copy link
Contributor

krzysz00 commented Jan 1, 2022

I'd like to add that I'm seeing this issue as well on NVDA 2021.3 - are there any steps I can take to try and debug this? (There doesn't seem to be a bdDetect available in the Python console these days).

If it helps, I'm using a F40B

@lukaszgo1
Copy link
Contributor

[...] (There doesn't seem to be a bdDetect available in the Python console these days).

NVDA's python console behaves much like the standard Python's REPL, and while only very limited subset of modules is available in its namespace by default, you can happily do: import bdDetect.

krzysz00 added a commit to krzysz00/nvda that referenced this issue Feb 11, 2022
Fixes nvaccess#9830

After control of the session is returned to the user
from the post-resume lock screen, I/O directed at some Focus Blue
braille displays would raise an error about the operation being cancelled,
causing the I/O thread to crash but not triggering a restart
of the display driver, leading the display to not function correctly
until NVDA was restarted.

This commit adds a callback that allows the I/O exception
thrown in hwio to be supressed and uses it to terminate and
reinitialize the Braille display after resume.

One flaw with the current strategy is that the termination can
cause more I/O requests to be cancelled, leading to repeated
renitilization.
seanbudd added a commit that referenced this issue Feb 11, 2022
Link to issue number:
Fixes #9830

Summary of the issue:
NVDA doesn't correctly regain control of some Focus Blue displays after the user has left the post-resume secure desktop. When in this state, Braille is only sent to the display when on a secure desktop. To regain normal functionality, the user must restart NVDA, possibly after unplugging the display and plugging it back in again.

From a technical perspective, the failure mode shows up as an error 995 (referring to cancelled I/O operations) in the background reader thread, which then leads to all the ack packets timing out.

Description of how this pull request fixes the issue:
This PR adds an onReadError callback to hwIo, which allows hwIo users to handle I/O errors that can't be caught with a try/catch (since the exception happens on a different thread).

It then uses this callback to detect the interrupted I/O characteristic of the post-resume failure state. When the issue occurs, the driver is terminated and reinitialized.

Testing strategy:
I suspended and resumed my computer while running a development build that included this fix and observed that, unlike with the latest release, the Braille display reflected changes to what I'd typed in a terminal after resume, instead of consistently showing "Secure Desktop".

I also checked the logs to ensure that the driver was only initialized once and that there weren't other exceptions being thrown as a result of this change.

* Reinitialize Freedom Scientific displays on I/O cancellation

Fixes #9830

After control of the session is returned to the user
from the post-resume lock screen, I/O directed at some Focus Blue
braille displays would raise an error about the operation being cancelled,
causing the I/O thread to crash but not triggering a restart
of the display driver, leading the display to not function correctly
until NVDA was restarted.

This commit adds a callback that allows the I/O exception
thrown in hwio to be supressed and uses it to terminate and
reinitialize the Braille display after resume.

One flaw with the current strategy is that the termination can
cause more I/O requests to be cancelled, leading to repeated
renitilization.

* Lint

* Clean up the logic, go for better function names

* update changes

Co-authored-by: buddsean <sean@nvaccess.org>
@nvaccessAuto nvaccessAuto added this to the 2022.1 milestone Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants