[RFC] RandR 1.3 properties

[Keith Packard]

On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote:

> - Apparently there are only 8, 16, and 32bit integers available as
>   property types. Having ATOMs and FLOATs would add semantics, which
>   could help in some cases. But if this implies some changes throughout
>   the system, I don't think this is helpful. If it's basically xrandr,
>   it would be easy.

ATOMs are obviously supported, but FLOATs seem harder as they aren't
described in the core protocol anywhere.

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

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

For the TV signalling type, I think we'll need more options; PAL has a
lot of variants that we'll want to expose. I'm also thinking we want to
expose a separate TV signalling property and leave the general property
as 'TV' or some such.

> - Panning - Keith indicated pretty strongly that this should be part of
>   the protocol level, and not a property. Haven't dealt with that yet,
>   it's still in the diff.

Yeah, we'll need stacks of code to manage this property, so it's not
just informational like most of the other properties.

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

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081028/84a93cec/attachment.pgp>