<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - [r128] Changes needed for RandR support" href="https://bugs.freedesktop.org/show_bug.cgi?id=75629#c23">Comment # 23</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - [r128] Changes needed for RandR support" href="https://bugs.freedesktop.org/show_bug.cgi?id=75629">bug 75629</a> from <a class="email" href="mailto:agd5f@yahoo.com" title="Alex Deucher <agd5f@yahoo.com>"> Alex Deucher</a> <pre>(In reply to <a href="show_bug.cgi?id=75629#c21">comment #21</a>) > Created <a href="attachment.cgi?id=99793" name="attach_99793" title="Patch with detection">attachment 99793</a> <a href="attachment.cgi?id=99793&action=edit" title="Patch with detection">[details]</a> <a href='page.cgi?id=splinter.html&bug=75629&attachment=99793'>[review]</a> [review] > Patch with detection > > I could not find changes to hardware state before and after the vbe stuff > but I found an easier way to detect monitors. That is a simple call to > xf86I2CProbeAddress(). In other words, xf86DoEDID_DDC2() was getting far > enough to tell that there was a monitor. It only returned NULL because it > was not getting a valid EDID. There wouldn't be any changes in the state before and after. You'd need to trace the actual EDID fetch process to see which gpios are used for i2c. > > Detecting the valid modes with EDID would be nice, but I think this solves > the most important problem. The driver now knows whether a monitor is > plugged in and hence whether to drive Crtc2. If you agree, I will send this > patch to the list. Does it actually change when you have a monitor vs. not? If probing works, you are probably pretty close to getting full i2c working.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>