RandR 1.3 additions?

[Alex Deucher]

On Jan 22, 2008 11:42 AM, Matthias Hopf <mhopf at suse.de> wrote:
> On Jan 22, 08 11:26:05 -0500, Alex Deucher wrote:
> > > I think I pretty much stated that in the properties I proposed.
> > > It still has the advantage of being backwards compatible.
> >
> > right, but from the looks of it, they still expose the encoders rather
> > than the physical connectors.  We shouldn't need
>
> Yes, because I didn't want to change the backward compatibility.
> RandR 1.2 was centered around outputs (what now seems to be called
> encoders), and this seemed to be the only way to deal with it on this
> abstraction level.

right now this varies from driver to driver.

>
> > "RANDR_CONNECTOR_NUMBER" or "RANDR_OUTPUT_NUMBER".  We don't want to
> > expose a DVI-I port as DVI-digital-0 and DVI-analog-0, we want to
> > expose DVI-I-0.  "RANDR_CONNECTOR_TYPE" and "RANDR_SIGNAL_FORMAT"
>
> Theoretically speaking, yes, that would be preferable, by having
> connectors abstracted. Major protocol change, though. This also shows
> the downside of a dedicated protocol IMHO.
>
> > could be used as the "standard" properties for choosing an encoder
> > though.  That said I think in the long run having encoder objects is
> > clearer.  It's be nice to know that the VGA port and the TV port
> > shared the same actual encoder rather than just signal format
> > "analog."
>
> Signal formats for VGA and TV differ significantly enough. "analog" is
> certainly no valid description for a signal format, and hasn't been
> proposed in the spec update.

Right, but my point was that you want to know which encoder is used
rather than just the signal format.  The encoder would dictate the
signal format.    Although I suppose you'd want both since it would be
nice to have a standard way of knowing the signal type as well.

Alex