RandR version 1.2 revisited
xavier.bestel at free.fr
Fri Sep 15 00:25:42 PDT 2006
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
I was more thinking about all non-PC hw running X, like PDAs and
embedded systems (does OLPC have EDID ?).
More information about the xorg