Update the connectorInstance field description #1101
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
'type' in this context is too vague. It seems that it may be referring to `DISPLAYCONFIG_TARGET_BASE_TYPE.baseOutputTechnology`? We were trying to use `connectorInstance` as part of a composite key that would uniquely identify each target monitor connected to an adapter. However, a test system with three monitors connected returned **0** for each of them. The same system with two of those monitors disconnected (leaving only the primary monitor) returned **1** for connectorInstance. **`connectorInstance`** seems to need a clearer, more comprehensive explanation. I think it would also be very helpful to identify the fields (from various CCD structs) that, taken together, uniquely identify a target device, and are stable between OS restarts. It seems to me to be a common requirement to identify a display, associate some data/state to it, persist that data between runs of an app, and then retrieve it and use it to locate that display again (if it's connected). We thought connectorInstance would be a good way to do that, but it seems not. Since Microsoft's **Display settings** app seems to do all of this, some explanation would be very helpful and avoid a lot of empirical experimentation...
|
@mr-intj : Thanks for your contribution! The author(s) have been notified to review your proposed change. |
|
Forgot to add this link, which provides additional information/context: |
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.
'type' in this context is too vague. It seems that it may be referring to
DISPLAYCONFIG_TARGET_BASE_TYPE.baseOutputTechnology?We were trying to use
connectorInstanceas part of a composite key that would uniquely identify each target monitor connected to an adapter. However, a test system with three monitors connected returned 0 for each of them. The same system with two of those monitors disconnected (leaving only the primary monitor) returned 1 for connectorInstance.connectorInstanceseems to need a clearer, more comprehensive explanation.I think it would also be very helpful to identify the fields (from various CCD structs) that, taken together, uniquely identify a target device, and are stable between OS restarts. It seems to me to be a common requirement to identify a display, associate some data/state to it, persist that data between runs of an app, and then retrieve it and use it to locate that display again (if it's connected). We thought connectorInstance would be a good way to do that, but it seems not. Since Microsoft's Display settings app seems to do all of this, some explanation would be very helpful and avoid a lot of empirical experimentation...