On Wed, 2009-05-06 at 03:12 +0100, Dave Airlie wrote: > Well if you just call the get_edid and ignore all the setscl crap that > this code does, then you should be able to just implement a new i2c algo, > and have it all just work.
Not completely; the rest of the DDC stack assumes that the underlying algo is bit-bang. I've got patches in my kernel tree that I'm doing the DisplayPort work in ssh://people.freedesktop.org/home/keithp/drm-intel on the display-port branch. I had to switch the intel_output->ddc_bus from a 'struct intel_i2c_chan *' to a 'struct i2c_adapter *' because intel_ddc_probe was using that to call i2c_transfer. I'm not happy with that patch yet; the DVO modules need to save the target i2c address somewhere, and so the patches above pull it out of the containing intel_i2c_chan when passed an i2c_adapter. > I've no idea what monitors this picks up on, radeon used to do it, and the > kernel fb layer does it but I think got it from radeon originally. > > I suspect dropping it might not be a bad idea. I wouldn't mind having it do this in the VGA stack; I hope to never use one of those again, and we load-detect before trying DDC, so 'regular' users should never hit this path. I do worry about making really old and crufty monitors stop working. -- keith.pack...@intel.com
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
