Monitor detection state after a driver change
A state vocabulary for GPU activation, display-path enumeration, monitor identification, and mode publication.
Detection is a sequence
A graphics adapter can be represented and active before a display path is enumerated. The path can then expose a connector or dock, read monitor identification data, and publish capabilities or modes. “Detected” can refer to any of these layers, so the owner should be named.
Monitor and adapter identities differ
The GPU or display adapter has hardware and package records, while the monitor has sink-side identification and capability records. A change in one record does not automatically establish a change in the other.
Mode publication follows capabilities
A display subsystem combines adapter support, connector constraints, monitor timing data, and display policy to publish modes. The mode list is a derived representation, not a direct version readout from the graphics package.
State after a transition is local
A package transition can affect adapter runtime, path enumeration, or monitor records at different times. A reference compares package, adapter, path, monitor, and mode observations at their own boundaries instead of treating one status as a complete explanation.
Reference facts
- Detection stages
- Adapter, path, connector, monitor, capability, and mode publication
- Identity boundary
- GPU package and monitor record are separate
- Derived record
- Mode lists combine adapter, path, monitor, and policy inputs
Questions and answers
Does an undetected monitor prove the panel is absent?
No. The phrase can describe a display-path, connector, identification, or mode-publication state.
Can a monitor be identified while no mode is published?
The records have different stages and owners, so identification and mode publication should not be treated as one event.
Does a graphics package change identify a monitor state?
No. Adapter package and monitor capability records are separate observations.