[Bug 86202] Intel/VLV: EDID readout on DP port (with DP display connected) gives random results

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Nov 26 11:20:32 PST 2014


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

--- Comment #7 from Egbert Eich <eich at pdx.freedesktop.org> ---

> 
> Ugh. That patch really shouldn't fix EDID reads. But I guess it's possible
> this is another one of those broken monitors that return garbage to AUX
> reads while waking up, and the locking makes the operation slow enoguh that
> the monitor falls back asleep between messages :( Either that or we have
> some nasty bug in our aux code somewhere that causes this. Is it a HP ZR24w?
> 

The monitor is a DELL 2212HM in fact.
I agree, this should not happen even it I2C read out is slowed down
considerably.

> If the problem is widespread and the aux code is not at fault, I'm thinking
> we may want to pursue the idea of waking up the sink around AUX transfers. I
> did think about doing that at some point. The main complication is making
> sure the sink doesn't get turned off when it should remain on. So maybe a
> ref count is needed, or maybe we have enough locking in place to make sure
> we can just return the sink to the same power state where we found it.

Right. Maybe you have seen the discussion Daniel and I had on the intel-gfx at .
I had a really simplistic approach but Daniel was afraid that this will not
scale when adding more DP AUX transfers.
So implementing this the proper way is actually on my TODO. I didn't get to it,
yet.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20141126/e75c0490/attachment.html>


More information about the intel-gfx-bugs mailing list