nvaccess
Braille does not work on secure Windows screens while normal copy of NVDA is running
Reported by kevinchao89 on 2012-05-10 13:40 When using APH RefreshaBraille, there is no Braille support when on Windows logon screen.
Steps to Reproduce:
- Ensure NVDA is configured with APH RefreshaBraille 18;
- WINDOWS+L to lock Windows
- Read content using Braille display Expected: read, navigate, and input suing APH RefreshaBraille 18 Actual: Speech-only support/access
Comment 1 by bramd on 2012-05-10 13:51 Please make sure your configuration is active on the login screen by saving the configuration and using the button in the General settings dialog to aply it to the logi nscreen and other security screens. Please test again and report your results.
Comment 2 by kevinchao89 on 2012-05-10 14:58 I have all my saved settings, including Braille display/settings set to be used on Windwos logon screen and other secured screens. For extra measure, I wnet ahead and configured everythign again, saved, and stold NVDA to use saved settings on Logon and other secured screens. Unfortunately, locking the PC, Braille only displays "secure desktop"
Comment 3 by jteh on 2012-05-10 22:43 Just to clarify the issue, please do the following:
- Disable braille in your normal copy of NVDA. Do not save your settings.
- Press Windows+l to lock Windows. Does braille work now?
Comment 4 by kevinchao89 on 2012-05-11 12:07 If I do one of two things, Braille will work on Windows logon screen:
- Per your request, disable Braille in normal copy and press WINDOWS+L
- Unload NVDA Otherwise, in normal configuration with NVDA running and braille is configured properly, Braille will not work on Windows logon screen.
Comment 5 by jteh on 2012-05-13 23:07 It's worth noting that the Windows logon and lock screens are different, hence the original confusion.
The problem here is that the normal copy of NVDA is using the braille display, so the copy running on the secure screen can't. We need to suspend braille output when switching to secure screens. This is unfortunately much harder than it sounds. :) Changes: Changed title from "Braille: Does NOT work on Windwos logon screen" to "Braille does not work on secure Windows screens while normal copy of NVDA is running"
I wonder whether this could have been fixed in the new Baum driver, which also applies to this display.
Not sure what you mean by "new Baum driver". While there have been significant updates, they've all been incremental updates to the original driver that landed in 2010.
Regardless, this isn't fixed. As I noted in https://github.com/nvaccess/nvda/issues/2315#issuecomment-155297694:
The problem here is that the normal copy of NVDA is using the braille display, so the copy running on the secure screen can't. We need to suspend braille output when switching to secure screens. This is unfortunately much harder than it sounds. :)
This is more of a core issue than a driver specific issue.
Woops, sorry for going mad there.
@jcsteh commented on 14 aug. 2017 09:05 CEST:
Regardless, this isn't fixed. As I noted in https://github.com/nvaccess/nvda/issues/2315#issuecomment-155297694:
The problem here is that the normal copy of NVDA is using the braille display, so the copy running on the secure screen can't. We need to suspend braille output when switching to secure screens. This is unfortunately much harder than it sounds. :)
This is more of a core issue than a driver specific issue.
Is this really so hard? We have gainFocus and leaveFocus event for the secure desktop, so couldn't braille just be de-initialized for gainFocus and initialized for leaveFocus?
@leonardder commented on 14 Aug 2017, 18:27 GMT+10:
Is this really so hard? We have gainFocus and leaveFocus event for the secure desktop, so couldn't braille just be de-initialized for gainFocus and initialized for leaveFocus?
Ah, if only things were as simple as it seems they should be. :) This essentially comes down to timing. What you suggest would work just fine if the secure copy always initialised after the normal copy received the gain focus, finished terminating the braille display driver and Windows released all resources associated with the display. The reverse must also apply when terminating the secure copy. In practice, things don't necessarily happen quite this smoothly. I think the secure copy would need to retry initialisation (perhaps after a short delay) if initialisation failed the first time. The normal copy would likewise need to do this when re-initialising braille after returning from a secure screen.
@jcsteh commented on 14 aug. 2017 13:20 CEST:
... Windows released all resources associated with the display...
Talking about freeing resources and access permissions, have you considered opening the HID file handles with FILE_SHARE_READ and FILE_SHARE_WRITE access parameters? Also, how about default permissions on the handles that pyserial creates?
I think having them open with shared access is risky. Writes from multiple clients might get interspersed, which could cause all sorts of pain.
Based on NVDA Remote, we could also go for a completely different implementation. When NVDA is running under the current user profile and the secure desktop is activated, create a socket that allows sending speech sequences and braille cell output from the secure copy to the user copy. In that case, speech and braille on secure screens will always match the settings for the local user. This becomes problematic when user switching comes into view or when the user copy of NVDA freezes in such a way that it couldn't longer output speech or braille. However, if the local copy acknowledges every "packet" it receives, the secure screen copy could easily fall back to stand alone speech and braille output as in the current situation when no acknowledgement have been received within a certain period.
Has anyone looked at this issue lately? From a user comment this morning I believe it is still present.
It is still present. My advise would be to wait for Python 3 and a possible integration of NVDA Remote into core.
@seanbudd You gave this a milestone of 2023.1, is this something NV Access wants to consider implementing?
I'm currently intending to write a proto type that adds a special braille display driver for this to NVDA that will be active on the secure screen. The secure screen copy of NVDA will send braille to this driver, which will use a named pipe to communicate the braille output to a named pipe server that will be running in the copy of NVDA that's currently active in the user session. This is also related to https://github.com/nvaccess/nvda/issues/3564#issuecomment-1363206466 in that said driver can be reused for a remote desktop implementation, the underlying connection will be the only thing that differs, but basically it's just writing data to a file handle. The Rust backend I wrote for the remote desktop connection is also based on named pipes, so lots of intentional overlap in scope of the two projects.
It was initially a serious candidate for 2023.1. After the delays to 2022.4/2022.3.3 we are yet to re-evaluate, but I imagine we won't be completing this in 2023.1. If you do intend to implement a fix for this issue, I suggest doing it separately to the project you describe.
Not sure how #14531 closed this issue, but this is certainly not fixed. #14531 was a step in the right direction though.
@leonardder just doing curiosity not wanting to cause any pressure, referring to what you write here, do you have plans for this issue?
It's already part of the add-on but it is not yet stable enough to be ported to NVDA core.