While fixing up xrandr to use the new SetCrtcConfigs request, and writing a compositing manager to use per-crtc pixmaps, I came up with a couple of necessary changes to the proposed RandR 1.4 specification.
There are three changes: 1) SetCrtcConfigs now takes flags that specify which values are to be used in the request. This lets clients make small changes without needing to completely respecify the rest of the current configuration. There's a 'screen' set of flags, and a 'crtc' set of flags'. I made the encodings not overlap to reduce errors... 2) per-crtc pixmaps now automatically resize as needed to deal with mode changes. This allows the user to continue to use existing randr tools (like xrandr) with a compositing manager that uses per-crtc pixmaps. 3) When a crtc pixmap is destroyed by a client, it is detached from the crtc automatically. This means that when the composting manager crashes, you get your screen back. I've pushed the RandR proto changes to the randrproto repository; a bit of review there would be helpful. Should I push the libXrandr changes out as well? Or should I pend those until the protocol changes are checked? I've got the SetCrtcConfigs flag X server changes all done, and will post those shortly. The crtc pixmap changes should be quite minor by comparison, and will only impact environments actually using crtc pixmaps, so I'm less worried about those. Again, none of these changes affect the driver API or ABI; they're purely DIX/protocol changes to clean things up at that level a bit. -- keith.pack...@intel.com
pgpu7IOgZEYxa.pgp
Description: PGP signature
_______________________________________________ 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