randr provider object

[Michal Suchanek]

On 6 May 2012 18:51, Dave Airlie <airlied at gmail.com> wrote:
> Hi,
>
> so as part of hotplug I've started to specify a "provider" object to
> basically represent a GPU.
>
> http://cgit.freedesktop.org/~airlied/randrproto/commit/?h=provider&id=670d2762a5c92da778fc3be4ad5a6b952e4f4027
>
> The idea of a provider is you have multiple providers per protocol
> screen, and they have a list of roles.
>
> Current roles are:
> a) master - a fully rendering and displaying GPU - initially I'd allow
> only one master per screen, when the code gets to replacing xinerama
> (i.e. shatter works) then we'd allow multiple masters per protocol
> screen.
>
> b) offload slave
> This is a slave device that can offload DRI2 operations to. i.e. GL
> and VDPAU so far. This is what the second GPU in an optimus laptop
> would be.
>
> c) output slave
> This is a slave that we can offload a chunk of the screen outputting
> to. It doesn't render any operations. The idea would be the primary
> master GPU would provide a shared shadow pixmap with the slave, and
> the primary GPU would take care of dirty updates to that pixmap, and
> the slave output would just scanout. USB output devices are one use
> case, the other would be for the intel GPU on optimus systems where
> the nvidia is in charge of rendering the desktop, but cannot write
> direct to the LVDS/eDP.
>
> The provider object also contains the list of crtcs and outputs
> controlled by this provider.
>
> The set provider API is then used to dynamically do things, like
> attach/detach output slaves, switch an offload slave into a master
> (GPU switching), etc.
>
> I'm just wondering what other info I should or shouldn't be including
> in the provider, I sort of think some sort of device identifier or bus
> id would be useful, maybe the input guys have some stuff they found
> useful to know. Like we'd probably need a way for GUI tools to display
> info about the provider like a name or something.

Name is one useful thing.

Device id another (in case name is not available or is ambiguous).

Bus attachment is another useful thing (in the case you have 2+
identical cards that only differ by the slot in which they are
inserted).

One problem is even if you know the PCI ID (& sub-id & revision) of a
PCI or USB device you don't know what device you have in many cases
because the exact model can be only determined once the device is
probed by the driver. Since it is a KMS device it should be already
probed by the time X gets to it.

Maybe a reference to /sys node that contains all this and more would
be most helpful on systems that have /sys enabled and mounted. Not
sure if that is always the case or any similar reference can be
provided on systems with /sys disabled and non-Linux systems.

Thanks

Michal