On Tue, 2008-12-16 at 17:37 -0500, Alex Deucher wrote: > > The EDID for the built-in monitor of all PowerPC Macs can be found > > under /proc/device-tree. Since it's hard for anyone but Apple to > > know about every single type of monitor they've put into their > > computers, wouldn't it be better for the radeon driver to find the > > EDID at runtime by looking in the OpenFirmware device tree rather > > than relying on a possibly inaccurate and out of date static quirk > > list? > > > > I think the xresprobe utility has a file called ddcprobe/of.c that > > does exactly that (ie. parses the OpenFirmware device tree and > > extracts the EDID). Why doesn't the radeon driver just use > > ddcprobe/of.c? This would seem the most robust way of getting EDID > > on all Apple PPC computers (iMac, Emac, Clamshell, Powerbook, > > PowerMac, etc). > > I didn't realize this existed. Does the OF tree have hardcoded edids, > or does it just read the edid from the device and store it in the > tree? if it just reads from the device (which I suspect it does), > then it's doing the same thing the driver is already doing. Most > built in apple screens (ibooks, powerbooks, imacs, etc.) have an edid, > it's just the eMac that seems to not.
The preferred thing to do for this case is to try the normal DDC path first, and fall back to platform methods after if DDC fails. I had some code to do similar for ACPI a while ago, I should look at reviving that. There are definitely a few laptops where DDC doesn't work on LVDS but the firmware does have a vaguely plausible EDID somewhere. - ajax
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
