[RFC] RandR 1.3 properties

[aplattner at nvidia.com]

On Wed, Oct 29, 2008 at 11:22:08AM -0400, Adam Jackson wrote:
> 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?

I agree that RANDR_BANDWIDTH is not that useful.  There are a million
different bandwidth constraints in modern GPUs and communicating them to an
X client in such a way that the client can validate modes is just plain
impossible.  Even a "validate this mode" request is insufficient because a
given mode on a given output may or may not work depending on the modes on
the other outputs, which GPU features are enabled, the current power state
of the GPU, etc.

> > > - 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.

While we're at it, is there any chance we could not have
ANNOYING_ALL_CAPS_NAMES_THAT_IMPLY_THAT_THE_SERVER_IS_YELLING_AT_YOU?