On Thu, Jun 6, 2013 at 9:49 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jun 06, 2013 at 12:17:26AM +0200, Daniel Vetter wrote: >> On some chipset we try to avoid possibly invasive output detection >> methods (like load detect which can cause flickering elsewhere) in the >> output poll work. Drivers could hence return unknown when a previous >> full ->detect call returned a different state. >> >> This change will generate a hotplug event, forcing userspace to do a >> full scan. This in turn updates the connector->status field so that we >> will _again_ get a state change when the hotplug work re-runs in 10 >> seconds. >> >> To avoid this ping-pong loop detect this situation and clamp the >> connector state to the old value. >> >> Patch is inspired by a patch from Knut Peterson. Knut's patch >> completely ignored connector state changes if either the old or new >> status was unknown, which seemed to be a bit too agressive to me. >> >> References: http://lists.freedesktop.org/archives/dri-devel/2012-August/025975.html >> Cc: Knut Petersen <Knut_Petersen@xxxxxxxxxxx> >> Cc: Alex Deucher <alexander.deucher@xxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> > > Also Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > I don't think this has any effect for i915, the circumstances where it > might we return connector->status rather than Unknown, so we need some > input from nouveau/radeon/architect as to our sanity. Hm, now I'm confused. The case I've had in mind indeed already works on i915.ko, but Knut's bug report was on a i915gm. The only place where we return unknown is when force==true and we can't get a load detect pipe. That shouldn't be able to ping-pong ... Knut, can you please shed some clue on me here? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
