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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
