On Tue, 2008-10-28 at 14:37 -0700, Keith Packard wrote: > On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote: > > - Is RANDR_BANDWIDTH helpful? Or should we have a dedicated property for > > indicating dual link capability on DVI? What other meta information > > (also on other connections) would be useful? > > I think it would be better to just indicate that this is a dual-link > connector.
This gets slightly more obscene with DisplayPort, where you get a choice of 1, 2, or 4 lanes, at either of two lane rates. There also seems to be an escape hatch in HDMI to let you declare arbitrarily high crossover frequencies, I've got a monitor that claims a max of 225MHz on the (single-link) HDMI port. Exposing link count and link rate would give the user all the information we've got, I suppose. I'm having some trouble understanding what the use case is for this property though. If the idea is to give the user some way to know if they can force a given mode, then this will help, but won't be complete. Low end chips like RN50, for example, won't have enough memory bandwidth to satisfy all the modes they can program. We may end up needing to add a validate-this-mode request to the protocol? > > - Should RANDR_CONNECTOR_TYPE be made mandatory? > > If a driver *really* doesn't want to implement anything here, it could > > always set this to '0' and be done. > > Yes, we should make several of these required. I'm wondering how well we > can do in automatically setting these from BIOS properties in the Intel > driver though. There's a lot of older chips where, if we ever add RANDR 1.2 support, we'll probably never be able to know connector type with precision. Likewise for dummy, fbdev, vesa, virtual machines where there's just no connector at all... All of which is fine as long as "unknown" is a valid answer. > > - So far we didn't have standard properties, and no RANDR_ prefix. > > > > EDID_DATA had been around since 1.2, should that be renamed to > > RANDR_EDID_DATA (as indidcated in the draft), be left alone (and the > > whole RANDR_ prefix idea burried), or cloned? > > I'd say that we should feel free to take over the unprefixed name space, > but that we should explicitly call out property names starting with '_' > as non-standard properties. Yes, please. - 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