On Wed, 2008-07-23 at 12:12 -0400, Matthias Clasen wrote: > On Wed, 2008-07-23 at 11:12 -0400, Adam Jackson wrote: > > I hacked up a proof-of-concept addition to the protocol along these > > lines: > > > > http://people.freedesktop.org/~ajax/patches/randrproto-1.3.patch > > > > I'm not completely happy with it, but it's at least a starting point. > > What API _do_ you want? > > > > (GetScreenResources is clearly an example of generalizing from too few > > examples. Let this be a lesson to you. > > Looks pretty good to me. It'll get us (almost) all the information we > want. The one thing that GTK+ exposes, which is missing is per-monitor > dpi, but we'll survive without it... After a hallway conversation with Matthias I want to amend this proposal slightly. The use case here is a slight superset of XineramaQueryScreens. The toolkit wants to know the borders of the glass so it can adjust window placement, and it wants to know output names so it can do things like maximize impress to the right bit of glass. The GetScreenTopology request given in the above patch returns merely the XIDs of the crtcs and outputs on the system; the toolkit will still need to roundtrip several more times to do a series of GetCrtcInfo (for the crtc rects) and GetOutputInfo (for output names), which is silly since the server could just as easily send them all up front. Since GST is likely to get called at least once per client, and probably during startup, minimizing round trips is desirable. Essentially the new RRGetScreenTopology would be: CRTCGEOMETRY { crtc: CRTC x: CARD16 y: CARD16 w: CARD16 h: CARD16 n: CARD32 o: LISTofOUTPUTS } OUTPUTINFO { output: OUTPUT n: CARD32 name: STRING8 p: pad(n) } ┌─── RRGetScreenTopology 1 CARD8 major opcode 1 25 RandR opcode 2 2 length 4 WINDOW window ▶ 1 1 Reply 1 unused 2 CARD16 sequence number 4 complicated reply length 4 TIMESTAMP timestamp 4 TIMESTAMP config-timestamp 2 c number of CRTCs 2 o number of outputs 12 unused 4c LISTofCRTCGEOMETRY crtcs 4o LISTofOUTPUTINFO outputs └─── Where n is the length of either the list of outputs or the output name, respectively, and is CARD32 just for the sake of staying dword-aligned. In case it's not clear, a CRTC is considered to participate in screen geometry if it has more than one output attached and has non-zero width and height, though this request will return all known CRTCs and outputs not just the enabled ones. Given this, it's not clear what a 'simple' version of GetOutputInfo should look like, or if one should even exist. I lean towards including a GetOutputBasicInfo that drops the physical w/h, connection status, and subpixel order from the reply relative to GetOutputInfo, but it's not clear that such a request would have a consumer. Feedback definitely sought here. And I'd send this on to the qt list too, if I had any idea what it was called... - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part