Braille does not work on secure Windows screens while normal copy of NVDA is running #2315
Comments
|
Comment 1 by bramd on 2012-05-10 13:51 |
|
Comment 2 by kevinchao89 on 2012-05-10 14:58 |
|
Comment 3 by jteh on 2012-05-10 22:43
|
|
Comment 4 by kevinchao89 on 2012-05-11 12:07
|
|
Comment 5 by jteh on 2012-05-13 23:07 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. :) |
|
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 #2315 (comment):
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:
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:
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:
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
added
p3
|
@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. |
|
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. |
…14531) Related to #3564, #2315 Summary of the issue: Currently, USB and Bluetooth devices are supported for braille display detection. Other devices using other protocols or software devices aren't supported. This pr intends to add support for this. Description of user facing changes None. User shouldn't experience anything different for now. Description of development approach Added Chain, a new extension point type that allows to register handlers that return iterables (mainly generators). Calling iter on the Chain returns a generator that iterates over all the handlers. The braille display detector now relies on a new Chain. By default, functions are registered to the chain that yield usb and bluetooth devices. A custom provider can yield own driver names and device matches that are supported by that particular driver. A potential use case would be implementing automatic detection for displays using BRLTTY, for example. It will also be used to fix Braille does not work on secure Windows screens while normal copy of NVDA is running #2315 (see below) Added a moveToEnd method on HandlerRegistrar, which allows changing the order of registered handlers. This allows add-ons to give priority to their handlers, which is especially helpful for both Chain and Filter. NVDA Remote should come for the braille viewer, otherwise controlling a system with braille viewer on with a 80 cell display connected to the controller would lower the display size to 40 unnecessarily. This will also be used to register a custom handler to bdDetect.scanForDevices to support auto detection of the user display on the secure screen instance of NVDA, which should come before USB and Bluetooth. As a bonus, added type hints to extension points. For Filters and Chains, you could provide the value type and then a type checker can check validity. As another bonus, all features are covered by new tests. So there are tests for the Chain extension point and for the specific use case in bdDetect Testing strategy: As this touches braille display auto detection quite a lot, probably merge this early in the 2023.2 cycle. Known issues with pull request: bdDetect.Detector does no longer take constructor parameters, rather queueBgScan should be called explicitly. This is because if we queue a scan in the constructor of Detector, the detector could switch to a display and disable detection before the _detector was set on the braille handler. Ideally we should use a lock as well, but that might be something as a follow up for both this pr and #14524. Note that though we're changing the constructor of a public class in bdDetect, the doc string of the class explicitly states that the Detector class should be used by the braille module only. That should be enough warning for users not to use this class and therefore I don't consider this API breaking.
|
@LeonarddeR "fix #2315" was in the body of the PR description |
|
@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.
|
|
Nice to hear! Then it will be there some day in the near future. |
|
Not very near, but certainly somewhere in the future.
|
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:
Expected: read, navigate, and input suing APH RefreshaBraille 18
Actual: Speech-only support/access
The text was updated successfully, but these errors were encountered: