Re: [PATCH] drm/i915: Always send a hotplug event after resume

[Daniel Vetter <daniel@ffwll.ch>]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx