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