[PATCH] randr: add provider object (v7)

[Dave Airlie]

On Mon, Jul 2, 2012 at 8:54 PM, Keith Packard <keithp at keithp.com> wrote:
> Dave Airlie <airlied at gmail.com> writes:
>
>
>> Yes thats going to be the standard on switchable GPU machines, two masters
>> and the ability to jump between them. In that case max master is one, and you'd
>> have to set the provider roles. If maxmaster > 1 then xinerama
>> emulation is available.
>
> In those machines, isn't the limitation that only one of them can drive
> the LVDS panel at a time? Can't you have the internal GPU driving the
> LVDS while the external GPU drives other outputs?

Yes but you don't configure it in xinerama mode for that, there are
mux and muxless configurations.

In mux configuration, you switch the mux between GPUs when the master
is switched.

In muxless, you go from have Intel connected to the LVDS as the
master, to the nvidia being the master with the intel being and output
slave driving the LVDS.

You don't want xinerama style operation in that situation at all.

>
> I think my confusion about this stuff starts with the notion of what a
> 'master' provider is.
>
> From my understanding, a 'master' provider is something which has
> outputs and a rasterizer, and to which slave providers can be attached.
> Slave providers can then either have outputs or a rasterizer, but not
> both, and they can't have further slaves attached.

Yup thats pretty much it.

> This seems to make a 'master' provider be effectively an implicit union of
> two slave providers -- an output slave and a rendering slave. And then,
> it takes on a completely separate role as the locus of connection
> between those implicit providers and more explicit slave providers.

Because we want to expose GPU level properties on the provider, also
currently the offload slave isn't a rendering slave per-say, there are
no circumstances where want to use the IGP GPU as an offload slave,
its simply not a configuration we should be exposing, and I see no
reason to advertise it.

> Would it not be simpler to eliminate the notion of 'master' provider,
> and simply have the screen reference a collection of providers, those
> providers having either 'output' or 'rendering' roles (or both)?

I don't think it would represent reality though, and I'd like to keep
a provider representing a whole GPU.
>
> And then, OUTPUTs for each 'output' provider would have a list of
> conflicting OUTPUTs from other 'output' providers, exposing the
> limitations of the hardware precisely.

Not sure what you mean conflicting outputs, you mean mux'ed ones where
we'd have an LVDS on each GPU? or do you mean crazy
connectors where EDID is wired to the intel, but data lines go to the nvidia.

>
>> Yes we probably need to spec that a bit better, things should go off
>> when transitioning from master->off, output slave->off,
>> but with a GPU switch you probably want to avoid turning off the intel
>> panel if you can since it would look smoother.
>
> The only way to do that would be to have an atomic mode set which
> reconfigured the providers and crtcs all at once. Before we get there, I
> think this request should require that all CRTCs and OUTPUTs on an
> 'output' provider be disabled before the provider is disabled.

Well the thing is, if someone rips the cable out, stuff goes away you
don't get to order it.

If we nuke the provider, everything will rescan if we send the Screen
Change notify.

Dave.