[Bug 47007] HDMI monitor polling causing 100ms rendering stalls

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47007

--- Comment #34 from Tvrtko Ursulin <tvrtko.ursulin at onelan.co.uk> 2012-03-16 03:54:47 UTC ---
(In reply to comment #32)
> (In reply to comment #31)
> > It is a single DVI-I physically.
> > 
> > But even identifying it would not change anything with regards to polling
> > induced rendering stalls, right? 
> > 
> 
> Well, shared_ddc wouldn't apply in that case since there is only one connector,
> and for better or worse we wouldn't be polling since the connector does have an
> HPD pin (even if it doesn't necessarily work reliably with the analog part of a
> DVI-I connector).  So fixing that would avoid the polling stalls on your
> particular board.

Now I know how to do the quirk to make only DVI-I appear instead of DVI-D and
VGA, however obvious limitation here is that:
 a) use cases from #18 are broken
 b) code seems to be buggy in bringing up even HPD enabled connectors anyway

Consider this for the latter:

* DVI monitor connected to DVI-I
* Unplug the cable
* HPD interrupt happens
* radeon_dvi_detect called
* DDC probe fails
* connector marked as disconnected
* output_poll_changed called,
* drm_helper_probe_single_connector_modes
* radeon_dvi_detect called again with force=true
* DAC load detect puts the connector in unknown status
* poll scheduled for ten seconds later
* ten seconds later radeon_dvi_detect called
* ddc probe fails
* connector still in unknown state
* Now plug the cable back in
* HPD irq fires
* radeon_dvi_detect called
* DDC is not ready yet for some reason and probe fails (I get this a lot)
* monitor still in unknown status
* end of story, no display

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.