RandR 1.4 restart

[Keith Packard]

On Mon, 7 Mar 2011 09:43:50 -0800, James Jones <jajones at nvidia.com> wrote:

> OK, I thought you wanted to completely hide the resize from
> applications.

I was only thinking about that from the RandR perspective so that
we can separate the resizing control from the compositing manager's crtc
pixmap adventures. So, I need to allocate a new pixmap and use it for
scanout, and I need an XID in the compositing manager's namespace. Seems
like the XID of the old scanout pixmap is ideal for this purpose.

> If the intent is to force GLX clients to re-create their GLX pixmaps
> when the underlying X pixmap resizes, then the design sounds clean,
> and should work fine as long as no one goes in and tries to "optimize"
> the destroy/create out of the server code.

Hrm. Given that the compositing manager will be the one using GLX with
this object, we need to figure out how to make it recreate the GLX
object.

> Is there some way to bake that into the protocol spec so 
> such an optimization would be non-compliant?

Just making the wording about creating a new pixmap, destroying the old
one and re-using the XID should suffice here.

> It seems a little ugly to require clients to know RandR events can make 
> certain GLX pixmaps no longer refer to the same resource they were created 
> against, but this is admittedly a special case, and one that shouldn't break 
> any existing applications.

No, the only applications involved here are compositing managers. They
have a rough life already, so we just need to make sure it works
correctly and with a minimum of visual disturbance on the screen...

> I don't know how to improve the interaction, but it sounds acceptable to me 
> within the constraints I mention above.  An explicit "pixmap changed" event (I 
> assume these resizes won't generate configure-notify on a pixmap some how...) 
> might make things clearer, but it might be overkill.

We'll get an event to the CRTC about the mode set at least. If the GLX
object can refer to the old pixmap until the compositing manager handles
the crtc notify event, I think that'll work.

> I think mentioning the issue in the protocol updates would be valuable though, 
> so future GLX/EGL/VDPAU-based composite manager coders don't need to dig up 
> this thread to understand what's going on with their CRTC pixmaps.

Yeah, making the protocol spec clear enough on this matter shouldn't be hard.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110307/7ccabcf1/attachment.pgp>