As mentioned in my EDID Spoofer Code, as well as the Tablet Bluetoother, I've run into what I think to be a bit of a design-flaw in OSX's handling of I2C (at least in 10.5.8)... The end-result seems to be that every I2C transaction via the DDC bus takes several milliseconds, and during that time, the entire system is halted (no mouse updates, etc.). This is fine if you're just reading an EDID once during boot, but I was hoping to use the DDC channel for other purposes! (At one time it was actually established to be used for things like tablets, etc!)
So here's a brain-dump, I might comment on it further, later.
http://opensource.apple.com/source/IOGraphics/IOGraphics-305.14/IOGraphicsFamily/IOFramebuffer.cpp
Check out all those IODelay() calls!
"IODelay, provided by the I/O Kit, abstracts a timed spin. If you are delaying for a short period of time, and if you need to be guaranteed that your wait will not be stopped prematurely by delivery of asynchronous events, this is probably the best choice. If you need to delay for several seconds, however, this is a bad choice, because the CPU that executes the wait will spin until the time has elapsed, unable to handle any other processing." https://developer.apple.com/library/mac/documentation/darwin/conceptual/kernelprogramming/services/services.html
Now, I'm not a genius when it comes to these things, but I've done a tiny bit with I2C in various projects, and I'm pretty-durn-certain there's absolutely nothing about it that has to be so precise that it couldn't be interrupted and resumed later. They're not bit-banging this thing! (Actually, looking into it further, maybe they are.) And, even if they were, I2C bit-rates are *way* faster than these IODelay() calls... And even if they were, it's a synchronous serial protocol, so should be relatively immune to even tremendous differences in bit-periods.
There's actually one piece in there (musta been an older version, because I can't find it now) where they insert a delay for 30milliseconds because of one particular monitor which happens to have a bug in its EDID... So, lemme get this straight, because of one monitor I've never even seen, every computer running this OS has to halt for 30ms looking for a monitor most people don't have? Thereby rendering a perfectly good communication-bus darned-near useless? Seems hokey, to say the least.
Anyways, using DDC for these various purposes I'd intended isn't really necessary, nor "standard"... it's just another tool that could've been handy. And, if you're using it for very short and very sparse transactions (less than once a second), it'd be unnoticeable.
-----------------