RandR 1.3 additions?

[Dirk Thierbach]

> Keith Packard <keithp at keithp.com> wrote:
On Tue, 2008-01-22 at 09:10 +0100, Dirk Thierbach wrote:

>> Also, every such block can get parameters, directly or indirectly,
>> from the modeline (which would also need to be generalized). Then we
>> would finally have enough infrastructure to support TV encoders on
>> external chips (some of which need a lot of paramaters which cannot be
>> easily calculated from the modeline as it is now).

> That, at least, is already available in RandR through output properties
> which can be made 'pending' and take effect on the next mode set.

I guess in theory one could encode everything as "just output properties",
but that doesn't reflect the underlying structure very well. The
Conexant chips, for example, need at least about three dozen values.

You're sure that it's better to add every single of them as an
seperate output property, in all drivers, instead of providing an
infrastructure that treats them like a unit, and allows one to
specify them as a named unit, similar to a modeline? Including a 
"database" of values that are known to work, also similar to the modeline?

And if you add every single one as output property (which may be
fine for the expert user), how should the average user be able to 
figure out the correct values? Add another output property that
allows to select predefined groups of these values by name? Then
you have output properties that influence other output properties...

>> Expose both, in a way that makes sense to the user. Also, provide
>> the user with some default paths, so he can just say "turn on the
>> monitor", "turn on both both monitor and TV", "turn on only TV".

> I think this just requires some conventions in output property names and
> values.

So how would this convention look like to capture all possible 
configurations? I am getting the faint feeling that "output properties" are
the hammer, and everything else starts to look like nails ... :-)

All my programmer's instincts tell me that this is bad design. Just
because there is a sufficiently flexible mechanism you can encode
every feature in doesn't mean that this is the natural way to express
the feature best. Maybe YMMV.

- Dirk