gtk+ and randr

[Adam Jackson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080724/46fdf9f8/attachment.pgp>