[RFC] RandR 1.3 properties

[Maarten Maathuis]

On Tue, Oct 28, 2008 at 10:37 PM, Keith Packard <keithp at keithp.com> wrote:
> 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
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>

Is there any chance to get rid of strings in the protocol/server
altogether and stick to standardised "names" and properties (in the
form of enums) as much as possible?
It would improve consistency for the standard stuff a lot.