RandR 1.3 additions?

[Alex Deucher]

On Jan 22, 2008 4:16 AM, Keith Packard <keithp at keithp.com> wrote:
>
> On Tue, 2008-01-22 at 02:04 -0500, Alex Deucher wrote:
> >  I would argue that connectors
> > are a better choice as that's what the user sees.
>
> Right, I want to at least allow the details of the hardware to be hidden
> by default and communicate with the user in terms of visible physical
> objects.

Exactly.

>
> >
> > the outputs would still handle the detect() functionality, and they
> > would choose the encoder.  A driver that didn't want to use the
> > encoders abstraction would still work so drivers could gradually
> > update or not.
>
> I'm not sure we need anything other than an output property that selects
> the desired encoder; is there something extra here?

It could be, but it's certainly not as clean.  The radeon driver does
that now.  There are several problems.  For one, most users don't even
seem to know that output properties exist.  Then the setup is
different across all drivers, and finally a lot more common state that
should be in the server (which actually has the full view) gets pushed
into the drivers which have to figure out what exactly the user wants
based on verious separate calls.  if you have encoders mapped to
multiple connectors and the user wants to turn one connector on and
the other one off, you have to keep the state straight in the driver
which can get complicated as various output entry points get called.
I think initially we could just add an encoder struct and some logic
to the xserver that the drivers could use or not use. If the driver
uses it, then the server would use the logic to do the right thing,
otherwise it would fall back to the old behavior.  For example, if the
driver uses the new encoder stuff, then when a user says turn on VGA-0
and turn off TV-1, the server would know they share an encoder and
wouldn't turn it off inadvertently rather than making the driver try
to do the right thing.  We could initially expose it as an output
property, but then add some sort of "official" protocol for it once we
sort it out.

Alex