Preventing assert on accessibility monitors. #7902
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This acts as both an issue and a proposal for fixing it. Some of my users are reporting that accessibility applications are installing virtual "monitors" which have a DPI of 0. This software for instance: https://www.freedomscientific.com/products/software/jaws/ Querying all monitors using glfw when the application is installed returns the following DPI for each monitor: ``` b'Freedom Scientific Accessibility Display Driver' = 0.0, 0.0 b'Generic PnP Monitor' = 1.5, 1.5 ``` This bubbles up into an assert eventually inside of ImGui: `mon.DpiScale != 0.0f`. The proposed change simply ignores monitors with a dpi scale of `0.0f`. My guess is the monitor exists to "duplicate" the main one, and be able to capture drawing primitives for the purpose of accomplishing its work. It's going to be difficult for me to test on other backends, given the software is expensive, and it's going to be tough to ask a visually impaired person to test many different backends, but I'm guessing other backends might want the same change.
|
Thanks! |
ocornut
pushed a commit
that referenced
this pull request
Aug 19, 2024
…ity virtual monitor?). to prevent assert. (#7902)
ocornut
added a commit
that referenced
this pull request
Aug 19, 2024
…g. accessibility virtual monitor?). to prevent assert. (#7902) I am not too confident on this but I believe pushing this is the fastest way we will get feedback.
|
Here's a dump of all the monitor's status for this user's system: |
|
Thank you! I admit those sizes are surprising too. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This acts as both an issue and a proposal for fixing it.
Some of my users are reporting that accessibility applications are installing virtual "monitors" which have a DPI of 0. This software for instance: https://www.freedomscientific.com/products/software/jaws/
Querying all monitors using glfw when the application is installed returns the following DPI for each monitor:
This bubbles up into an assert eventually inside of ImGui:
mon.DpiScale != 0.0f. The proposed change simply ignores monitors with a dpi scale of0.0f.My guess is the monitor exists to "duplicate" the main one, and be able to capture drawing primitives for the purpose of accomplishing its work.
It's going to be difficult for me to test on other backends, given the software is expensive, and it's going to be tough to ask a visually impaired person to test many different backends, but I'm guessing other backends might want the same change.