[PATCH] randr: add provider object (v7)

[Keith Packard]

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?

> +
> +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.

> +
> +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...

>  > +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.

> +7.4 Extension Requests added in version 1.5 of the extension.
> +
> +┌───
> +    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?

> +┌───
> +    RRSetProviderRoles
> +	providers: LISTofPROVIDER
> +	role: LISTofROLEMASK
> +     ▶
> +└───
> +	Errors: Provider, Match, Value
> +
> +	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.

(the property stuff looks insane, but insane in a way compatible with
the existing randr property stuff)

--
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20120702/e05a4805/attachment.pgp>