Re: Reading the EDID block for x86 machines

[Antonino Daplas <adaplas@pol.net>]

On Wed, 2003-03-12 at 20:10, Ville Syrjälä wrote:
> On Tue, Mar 11, 2003 at 08:49:46PM +0800, Antonino Daplas wrote:
> > Hi,
> > 
> > I was wondering how to get the EDID block, and my first thought was to
> > implement DDC.  But it is tricky to implement,
> 
> Forgive my ignorance but why is it tricky? As I understand it DDC1 only
> involves reading from the monitor or does EDID require something more?

It will require that each driver provide a means of getting the EDID
from the monitor, either via i2c or by some hardware specific means.
Matrox users are the fortunate few since the author implemented an i2c
backend.

> 
> Reading stuff from my monitor via /dev/i2c works fine with matroxfb. I
> just tried this and I can see my monitors model in the returned data but
> parse-edid doesn't understand the data so I'm not sure it's the EDID.
> 
> Also the BIOS solution will fail when someone decides to change their
> monitor. This got me thinking that with a real DDC solution would it be
> feasible to have the driver re-read the EDID periodically and/or on mode
> switch to prevent using bad modes?
> 

That's okay.  The get_EDID() function can get the EDID block several
ways.

1.  via the driver if it has its own method of getting the EDID block
(1st choice)

2.  via userland - EDID block (ie get-edid > edid.dmp) uploaded to
driver via ioctl (2nd choice)

3.  through an arch-specific method -- VBE for x86, OF for PPC, etc
(last choice)

When a user changes monitors without rebooting, he/she can upload an
edid block appropriate for the display.

Tony




-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open!
Get cracking and register here for some mind boggling fun and
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en