[RFC] RandR 1.3 properties

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081029/5da44677/attachment.pgp>