RandR version 1.2 revisited

[Adam Jackson]

On Thursday 14 September 2006 17:39, Xavier Bestel wrote:
> Le jeudi 14 septembre 2006 à 16:58 -0400, Adam Jackson a écrit :
> > I really can't justify reporting EDID to the client in any format but the
> > raw block.  It's quite easy to parse, and we've basically got the code
> > already, and translating it to another format is just making work.  I'd
> > be happy to split it out into a shared lib post-7.2 if people think
> > that's worthwhile.
>
> How do you export the properties of non-EDID displays then ? You just
> create a fake EDID ?

That's certainly an option, but I don't expect it to be a very common case.

EDID is actually required as part of the DVI spec, and I expect similar 
requirements for HDMI and other future standards.  ACPI even requires that 
EDID blocks be available via the DSDT if they're not available through any 
other means.  It's essentially a requirement for plug and play.

Now there are some classes of legacy devices for which we may want to 
construct fake EDID blocks, and the driver would have to gain some smarts to 
hook them up when possible.  Likewise VGA cables tend to lose their DDC pins.  
But it is now virtually impossible to buy a non-EDID monitor off the shelf, 
which is a trend we should encourage by treating monitors without EDID as 
broken.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060914/f23db8ba/attachment.pgp>