Jean Delvare wrote: > > By setting bit 7 resp bit 4 of I2C_CR it will be switched from > > plain I2C to DDC1 or DDC2 respectively. > > > > I didn't add code for it since it cannot be tested on this > > reference hardware, but if you like I can try to add that > > in anyway. Would be a module parameter to select mode > > plain I2C/DDC1/DDC2. Would that be nice? > > I am totally lost. To the best of my knowledge, DDC1 and DDC2 are > protocols on top of I2C. Other I2C controllers don't have anything like > a "DDC mode", they just do I2C and you can connect monitors if such is > your desire. No. (I really should finish and post my generic DDC driver at some point...) The E-DDC specification *says* it's just an I2C bus, but that is not reality if you want to work with real hardware of all ages and be robust. DDC1 is not I2C at all, and it's not compatible with I2C. DDC2 (actually it's DDC2B) and E-DDC are I2C, but both can get confused when talking to a DDC1 or dual-mode device. The very first data read over DDC2 can easily fail when it's to a dual-mode device. Same if there has been no activity for 2 seconds. With some devices and cables, DDC2 needs slower timings than I2C. And you can (rarely but possibly) corrupt a monitor if you plug/unplug it in the middle of a DDC2 transaction - something which is not allowed for in true I2C - so all future attempts to read that monitor's info fail the checksum. This is probably the reason for one of the quirk workarounds in Linux's EDID code. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
