After hibernate/resume, monitors connected through a dock (OWC Thunderbolt Dock in my case) could have their port mapping swapped.
This leads to wrong (stale) EDID/descriptions if two ports with screens connected are swapped after resume. The kernel DRM subsystem re-reads the EDID correctly (verified via /sys/class/drm/card0-DP-*/edid), but Aquamarine never re-reads it for already-connected connectors.
The logs seem to confirm this:
DEBUG from aquamarine ]: drm: connector DP-1, has crtc -1, will be rechecked
DEBUG from aquamarine ]: drm: connector DP-2, has crtc -1, will be rechecked
DEBUG from aquamarine ]: drm: connector DP-3, has crtc -1, will be rechecked
DEBUG from aquamarine ]: drm: connector DP-4, has crtc -1, will be rechecked
DEBUG from aquamarine ]: drm: connector DP-5, has crtc -1, will be rechecked
DEBUG from aquamarine ]: drm: Skipping connector DP-6, has crtc 83 and is connected
DEBUG from aquamarine ]: drm: Skipping connector DP-7, has crtc 87 and is connected
Replugging the dock causes a re-enumeation and fixes the issue but would it be possible to detect/handle changed EDID strings after resume?
After hibernate/resume, monitors connected through a dock (OWC Thunderbolt Dock in my case) could have their port mapping swapped.
This leads to wrong (stale) EDID/descriptions if two ports with screens connected are swapped after resume. The kernel DRM subsystem re-reads the EDID correctly (verified via /sys/class/drm/card0-DP-*/edid), but Aquamarine never re-reads it for already-connected connectors.
The logs seem to confirm this:
Replugging the dock causes a re-enumeation and fixes the issue but would it be possible to detect/handle changed EDID strings after resume?