RandR version 1.2 revisited

[Keith Packard]

On Wed, 2006-09-13 at 16:54 +0200, Xavier Bestel wrote:
> On Wed, 2006-09-13 at 08:56, Keith Packard wrote:
> > Discussions during DDC this summer prompted me to discard the
> > specification and implementation of the RandR upgrade I'd been working
> > on. I've finally managed to sort through the issues and come up with a
> > new proposal that purports to meet the requirements presented at that
> > meeting.
> 
> - In the CrtcInfo x and y are INT16, but it seems they can't be negative
> (a CRTC must fit within the screen).

Right. Positions in X are always INT16 though, so I think I'll leave it
-- the server has to bounds check the values anyway.

> - There should be a way for an app to specify it will sync to the vblank
> of a particular CRTC (for uncomposited cases I guess).

Yes, that's what the sync extension is for if it ever gets hooked up.
I'm not sure what RandR could do about this.

> - In "9. Extension Versioning" there are parts still written for 1.0.

More importantly, there's no exposition on 1.2. I'll add that.

> - IMHO, the subpixel order should be available in the Output, and the
> toolkit should take care of that (guess which Output/CRTC mostly applies
> to the window, select vblank, read subpixel order & gamma, etc. from
> it).

You're right, of course. I'll move it and let the application figure out
the current subpixel order from the rotation and the output order.

> - There should be a user-selectable "Driving Output" which will set the
> main subpixel order, main vblank, XVidMode target, etc. for applications
> unaware of RandR1.2. That may solve point 10.1.

I'm not sure we need to make this selectable; it's purely a migration
issue, and few (if any) applications actually listen to this part of
RandR in any case. I suggest we just fix a simple policy (like sub-pixel
order always follows the first output in the list driven by the CRTC,
(which is user-selectable, btw)

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060913/49be1980/attachment.pgp>