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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
