[PATCH] randr: add provider object (v7)

[Dave Airlie]

On Mon, Jul 2, 2012 at 7:19 PM, Keith Packard <keithp at keithp.com> wrote:
> Dave Airlie <airlied at gmail.com> writes:
>
>
>> +PROVIDER { XID }
>> +
>> +MAXMASTER { CARD16 }
>> +     Maximum number of master GPUs server can support.
>> +     1 unless dynamic xinerama is enabled.
>
> You don't need a type for this; it's just a count, right?

true, wasn't sure of the rules for this.

>
>> +
>> +FLAGS { Dynamic }
>> +     Informational flags about acceptable configurations.
>> +     Dynamic: The server can accept changes to the device roles.
>
> Is this necessary? I'd think a provider which had roles == current_role
> could not be changed, and that it's possible to have some providers
> which have multiple potential roles and some providers which have only
> one. Seems weird to summarize information across disparate hardware in a
> single boolean here.

Yeah I was trying to think of a case where this might be needed, and
maybe you are right, nothing springs to mind.

I was mostly thinking of the case where we merged providers but
nothing else, but a provider with one role and no abilities would
cover it.

>> +ABILITYMASK { Offload, Output }
>> +     Abilities that this device can work with.
>> +     Offload: This device as a master can work with offload slaves.
>> +     Output: This device as a master can work with output slaves.
>> +
>> +ROLEMASK { Master, Offload, Output }
>> +     List of roles a device can have.
>> +     Master: A primary display and primary renderer.
>> +     Offload: A rendering offload device.
>> +     Output: An output slave device.
>
> Might prepend 'PROVIDER' to these as well; they're not quite as generic
> as 'FLAGS', but still...

make sense.

>
>>  > +7.3. Extension Requests added in version 1.4 of the extension.
>> +
>> +                           ❧❧❧❧❧❧❧❧❧❧❧
>> +
>
> There is no version 1.4 of the RandR extension; this section shouldn't
> be added.

Okay I wasn't sure if the stuff that was left in 1.4 was useful to
note, but probably isn't.

>> +┌───
>> +    RRGetProviders
>> +     window : WINDOW
>> +     ▶
>> +     timestamp: TIMESTAMP
>> +     providers: LISTofPROVIDER
>> +     maxmaster: MAXMASTER
>> +     flags: FLAGS
>> +└───
>> +     Errors: Window
>> +
>> +     RRGetPRoviders returns the list of providers connected to the screen
>> +     associated with 'window'.
>> +
>> +     'timestamp' indicates when the configuration was last set.
>> +
>> +     'providers' contains the list of PROVIDERs associated with the
>> +     screen.
>> +
>> +     'flags' contains the set of provider related flags for the screen.
>> +     Currently this is used to define if providers are dynamic or static.
>> +
>> +     'maxmaster' is the maximum number of master rendering devices the
>> +     server can support. (Dynamic Xinerama > 1, else 1).
>
> Are you thinking that we'll have configurations with multiple devices
> which support Master role but in which you can only have one Master at
> a time and must switch between them? And, if maxmaster != number of
> master devices, then how do I know which configurations are supported?

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.

>> +
>> +     RRSetProviderRoles allows the roles of the multiple specified providers
>> +     to be changed. If the number of providers and number of roles doesn't
>> +     match a Match error will be generated. If a provider doesn't exist a
>> +     Provider error will be generated. If the role isn't available for that
>> +     provider a value error will be generated.
>
> What requirements are there for the state CRTCs and OUTPUTs which are
> affected by this change? I'd think that you would require any CRTCs or
> OUTPUTs connected to a provider which is switching to a role which
> doesn't have any output would need to be disabled first.

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.

Dave.