Just define an ioctl for that and let each driver that support EDID
return something seem to be the simplest way.

Replying to myself... and definitely not the best way for 2.5
(would be ok for 2.4 but do we care at this point ?)

Instead, we'd rather add the EDID as an attribute of the fb
to sysfs.

Actually, I suggest that each fbdev driver defines ones or more
nodes in sysfs below the actual driver node, representing the
various heads. Each head would then have attributes representing
the various display properties, one beeing the EDID block.

If we really want to make EDID a generic thing, then we can eventually
have the EDID block attached to each fb_info and then a generic
fbmem.c ioctl to read it, but then make sure that EDID block isn"t
mandatory (it has no sense to some specific HW like some embedded
stuffs) and I always prefer when drivers are the real target of
the calls like this ioctl, eventually using fbdev "tools" as helpers
instead of having fbdev do something directly as a "mid-mayer".

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

-- 
Benjamin Herrenschmidt [off-list ref]