[RFC] RandR 1.3 properties

[Maarten Maathuis]

On Fri, Nov 7, 2008 at 7:38 PM, Matthias Hopf <mhopf at suse.de> wrote:
> On Nov 07, 08 18:48:18 +0100, Maarten Maathuis wrote:
>> On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf <mhopf at suse.de> wrote:
>> > On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote:
>> >> 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?
>> >
>> > Sounds reasonable to me. We should still stick to ATOMs to make this
>> > extensible, but for the standardized values we should have standardized
>> > ATOMs.
>>
>> Just to be clear, i was also referring to output names, which have a
>> habit to be slightly different pretty much everywhere.
>
> I don't see that coming ATM. There are at least two different
> interpretations of what RandR outputs actually are, both with different
> pros and cons.
>
> We had a discussion on the radeonhd mailinglist whether to move to the
> interpretation used e.g. by radeon, but that would kill a few special
> cases, and consensus (well, that might be too strong a word, say >50%)
> was that we should stick with the current interpretation, with slightly
> less complicated names.

Perhaps now would be the time to standardise on a beheaviour, my
personal opinion is that, the
user should see something that represents the connectors on the back
of their computer. Anything else should become a property of that
connector (since it's automatic in 99% of the cases). Was there any
good reason in that discussion to do otherwise?

> Matthias
>
> --
> Matthias Hopf <mhopf at suse.de>      __        __   __
> Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
> Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de
>