RandR 1.3 additions?

[Maarten Maathuis]

On 1/22/08, Dave Airlie <airlied at gmail.com> wrote:
> 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
> >
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>

But it would be nice if the server had a concept which included
something in between a crtc and an output. This doesn't neccesarily
have to be exposed to users though.