randr provider object

Adam Jackson ajax at nwnk.net
Tue May 15 13:04:34 PDT 2012


On 5/15/12 3:04 PM, Dave Airlie wrote:

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

Not all XIDs are per-screen objects.  Sync counters are global.  Fixes 
Regions are global.  Probably a couple of others I'm forgetting?

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

That's perfectly cromulent, just wanted to be sure it got captured.  If 
providers weren't screen-scoped you'd have the horrifying prospect of 
migrating them between protocol screens.

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

My concern is how you're going to build this programmatically if you 
keep with a poke-one-thing model, I just envision intermediate states 
that don't make a ton of sense on their own but that we'd end up needing 
to allow.  What do you imagine the sequence of requests looking like?

- ajax


More information about the xorg-devel mailing list