RandR 1.3 additions?

[Dave Airlie]

On Jan 22, 2008 8:09 PM, Dirk Thierbach <dthierbach at gmx.de> wrote:
> > 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).

Shouldn't that all be dealt with in the drivers? I see no reason to
ever expose the setup of a tv encoder to the user,

we have many tv-encoders, from on-die ones to Conexant and other i2c
dvo chips.. and I think the drivers can abstract a set of user
properties to figure out the actual settings to program into the
device..

I see the need to perhaps export connectors rather than outputs, as
users understand connectors and physically see things plugged into
connectors but exposing the building block off gpus to users seems
pointless verbosity.

Dave.

>
> > 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
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>