<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - i915 i2c-dev failures with recent chips and docking stations" href="https://bugs.freedesktop.org/show_bug.cgi?id=100954#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - i915 i2c-dev failures with recent chips and docking stations" href="https://bugs.freedesktop.org/show_bug.cgi?id=100954">bug 100954</a> from <a class="email" href="mailto:rockowitz@minsoft.com" title="Sanford Rockowitz <rockowitz@minsoft.com>"> Sanford Rockowitz</a> <pre>Some observations. 1) What I see on dirty monitors is payload corruption, detected by the DDC/CI checksum. There are commonly duplicate bytes in the packet. 2) If there were an ioctl to control bus speed, ddcutil could change that before retrying a write/read sequence (used to read feature values and the monitor capabilities string). It would have be a bit clever about writes without a subsequent read (used to set a feature value) as there's no way to detect data corruption in that case. 3) If the i915 driver were to unilaterally slow down all I2C transactions for slave address x37 it would eliminate the possibility of per-monitor adjustments, but I don't believe it would have any perceived affect on performance. The DDC/CI protocol mandates that the host wait from 40ms to 200ms between writes and reads, depending on operation. ddcutil spends over 90% of its elapsed time in sleeps mandated by the DDC/CI protocol.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>