RandR version 1.2 revisited

[Xavier Bestel]

On Fri, 2006-09-15 at 00:19, Adam Jackson wrote:
> 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.

I was more thinking about all non-PC hw running X, like PDAs and
embedded systems (does OLPC have EDID ?).

	Xav