randr provider object

[Dave Airlie]

> I don't think you need (or want) outputs here.  GetCrtcInfo already gives
> you the current and possible mapping for crtc->output.

Well the main reason was just to provide the application the info in
an easy to find place about what resources are on what GPU,
so it can draw a pretty picture, we provide the info in GetResources
anyways so I was just paralleling that, but yeah it does look
like the info would be available through other means.

>> 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.
>
>
> This might be a little thin.  You have:
>
> typedef struct {
>    CARD8 reqType;
>    CARD8 randrReqType;
>    CARD16 length B16;
>    RRProvider provider B32;
>    Time configTimestamp B32;
>    CARD32 new_role B32;
>    CARD32 exclusive_master B32; /* xinerama or GPU switch */
> } xRRSetProviderRoleReq;
> #define sz_xRRSetProviderRoleReq 20

Well RRProvider is an XID, and the XID should be unique cross protocol
screens? same as we only pass RRCrtc to RRGetCrtcInfoReq or
RRSetCrtcConfigReq.

>  Alternatively, you can say that Providers are unique to a Screen (and
> therefore the Window isn't necessary).  But since there's no english
> description of the protocol...

Yeah providers are like crtcs/outputs, unique to a screen.

> I'm also not totally sure I like the "exclusive_master" field.  Or the whole
> Set request really.  The single worst thing about how RANDR is currently
> implemented is the damn poke-one-crtc-at-a-time model.  This just makes it
> worse.

I'm not sure I can really fix that with this though, thats a whole
project by itself, and if fixing the crappy history of X decisions
before we try and move on, we'll never get anywhere.

The reason for exclusive_master is just GPU switching, since it needs
to be an atomic operation, we don't want to keep both GPUs running,
maybe I can add a separate protocol request for GPU switch, but I
don't think it makes a huge amount of sense either.

I'll try and write up the text side of the protocol next :-)

Dave.