| Message ID | 20161021101607.26028-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Oct 21, 2016 at 11:16:07AM +0100, Chris Wilson wrote: > Curently after resume we reset all connector status to unknown and then > try to tell userspace about the probable changes (e.g. a laptop being > unplugged from one dock and plugged into another). However, we call > drm_helper_hpd_irq_event() to send the hotplug event to userspace which > first does a check of connector->status before deciding if userspace > needs to know about the event. This will filter out the above scenario > of one output being replaced because it only checks the status and not > whether the output is the same. > > Always send the hotplug uevent to userspace upon resume, and force it to > reprobe. Bah, since we no longer set the status to unknown, this alone is not enough to undo the damage. -Chris
On Fri, Oct 21, 2016 at 04:27:53PM +0100, Chris Wilson wrote: > On Fri, Oct 21, 2016 at 11:16:07AM +0100, Chris Wilson wrote: > > Curently after resume we reset all connector status to unknown and then > > try to tell userspace about the probable changes (e.g. a laptop being > > unplugged from one dock and plugged into another). However, we call > > drm_helper_hpd_irq_event() to send the hotplug event to userspace which > > first does a check of connector->status before deciding if userspace > > needs to know about the event. This will filter out the above scenario > > of one output being replaced because it only checks the status and not > > whether the output is the same. > > > > Always send the hotplug uevent to userspace upon resume, and force it to > > reprobe. > > Bah, since we no longer set the status to unknown, this alone is not > enough to undo the damage. I think we could fix this with the probe timestamp - if we read a new edid (the edid function in drm_mode.c could compare the contents) we increment the refcount. If the probe count changes on any of them, we fire the uevent away. At least that's kinda been my master plan to fix this mess: Instead of trying to make the right guess at the top-level code (like resume here), or trying to wire up fragile change reporting up our massive probe call-chains we do the detection at the very leaves. And the top level (well the helpers in drm_probe_helper.s) just watch that probe counter for changes. For even more safety we could store the probe counter for each uevent in drm_connector.c (and compare it with the new one every time the uevent helper is called), and so even avoid duplicating that bit of logic. -Daniel
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 4df75e63cf22..da944ca4298f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1606,7 +1606,7 @@ static int i915_drm_resume(struct drm_device *dev) * */ intel_hpd_init(dev_priv); /* Config may have changed between suspend and resume */ - drm_helper_hpd_irq_event(dev); + drm_kms_helper_hotplug_event(dev, NULL); intel_opregion_register(dev_priv);
Curently after resume we reset all connector status to unknown and then try to tell userspace about the probable changes (e.g. a laptop being unplugged from one dock and plugged into another). However, we call drm_helper_hpd_irq_event() to send the hotplug event to userspace which first does a check of connector->status before deciding if userspace needs to know about the event. This will filter out the above scenario of one output being replaced because it only checks the status and not whether the output is the same. Always send the hotplug uevent to userspace upon resume, and force it to reprobe. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)