On Mon, Jun 15, 2015 at 01:35:21PM +0100, Chris Wilson wrote: > On Mon, Jun 15, 2015 at 02:29:28PM +0200, Daniel Vetter wrote: > > On Fri, Jun 05, 2015 at 08:46:19AM +0100, Chris Wilson wrote: > > > For old-school component TV and CRT connectors, we require a heavyweight > > > load-detection mechanism. This involves setting up a CRTC and sending a > > > signal to the output, before reading back any response. As that is quite > > > slow and CPU heavy, the process is only performed when the output > > > detection is forced by user request. As it requires a driving CRTC, we > > > often don't have the resources to complete the probe. This leaves us in > > > a quandary where the unforced path just returns the old connector > > > status, but the forced detection path elects to return UNKNOWN. If we > > > have an active connection, we likely have the resources available to > > > complete the probe - but if it is currently disconnected, then it > > > becomes unknown and triggers a hotplug event, with often quite unfortunate > > > userspace behaviour (e.g. one output is blanked and the spurious TV > > > turned on). > > > > > > To reduce spurious hotplug events on older devices, we can prevent > > > transitions between disconnected <-> unknown. > > > > > > v2: Convert tv_type to use proper unknown enum (Ville) > > > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=87049 > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> [v1] > > > Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> [v1] > > > > This solution is at odds with > > > > commit b7703726251191cd9f3ef3a80b2d9667901eec95 > > Author: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Date: Wed Jan 21 08:45:22 2015 +0100 > > > > drm/probe-helper: clamp unknown connector status in the poll work > > > > We're missing this bit of logic from the hotplug handlers, but that was > > somewhat intentional since a hotplug should indicate that something has > > changed. And in the i915 hpd handler we filter by source. > > > > Given that the report is older than me having resurrect that patch can we > > close it as fixed or do I miss something? > > It's a different path. This also concerns the actual forced reprobe > fluctuating between two states. In that case I still think it should be in the probe helpers. Which raises the policy decision whether we should ever hand unkown back to userspace since apparently it just can't cope sensible with it. But that call should be done consistently accross drivers. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
