On Mon, Jun 15, 2015 at 02:37:58PM +0100, Chris Wilson wrote: > On Mon, Jun 15, 2015 at 03:03:39PM +0200, Daniel Vetter wrote: > > 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. > > Hmm, the probe helper is not the central arbiter here which is a problem > in moving it entirely into its domain. UNKNOWN makes a sense form the hw > perspective, and we still need to report that status before any probes > are made at all (whether that is init/resume) and the problem in this > case is not so much as userspace mishandling it, but the fluctuation > between UNKNOWN/DISCONNECTED is causing activity and reconfiguration not > entirely of its own fault. Well for the poll worker part of the probe helpers I went with if (new_status == unknown) connector->status = old_status; which takes care of the init/resume time unknown->(dis)connected transition correctly while filtering the noise. Adding that to the synchronous users probe function (which is the only one that sets force == true) would achieve what you want I think. But it also means that we almost always filter out unknown and never let userspace known that the hw detection is uncertain. Maybe we instead need a drm helper module option to clamp unknown uncondiotionally to disconnected to allow users to hack around silly userspace? -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
