randr provider object
Dave Airlie
airlied at gmail.com
Tue May 15 12:04:54 PDT 2012
> 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.
More information about the xorg-devel
mailing list