Re: [Linux-fbdev-devel] Reading the EDID block for x86 machines

[Antonino D. <ad...@po...>]

On Wed, 2003-03-12 at 20:10, Ville Syrj=E4l=E4 wrote:
> On Tue, Mar 11, 2003 at 08:49:46PM +0800, Antonino Daplas wrote:
> > Hi,
> >=20
> > I was wondering how to get the EDID block, and my first thought was to
> > implement DDC.  But it is tricky to implement,
>=20
> 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.

>=20
> 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.
>=20
> 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?
>=20

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