RandR 1.4 restart

[James Jones]

On 3/1/11 6:56 PM, "James Jones" <jajones at nvidia.com> wrote:

> On Tuesday 01 March 2011 08:02:24 Keith Packard wrote:
> *snip*
> 
>> Scanout pixmaps get resized automatically when the associated crtc gets
>> a new mode. This lets a compositing manager deal with the scanout pixmap
>> creation while separate screen configuration applications deal with mode
>> setting. Of course, internally, this is done by creating a new scanout
>> pixmap and pointing the existing XID at the new object. (Hrm. I wonder if
>> there are implications for DRI2/GLX/EGL here...)

I looked over the rest of the spec changes, and spent some more time
thinking about how bad it would be for GLX/EGL to have pixmaps resize.  It
looks pretty heinous.  A lot of the badness comes from
texture_from_pixmap/EGLimage extensions.  If the pixmap is bound to a
texture or EGL image, the size is derived from that pixmap.  At least for
GLX pixmaps, whether you want to use non-power-of-two textures (with
mipmapping support), normal power of two textures (with mipmapping support),
or rectangle textures (no mip-mapping, different texel coordinate system)
depends on the size of the texture as well.  The texture target is selected
at GLX pixmap creation time, so just re-binding the pixmap wouldn't be
sufficient to update all state.

As an alternative to resizing the scannout pixmap, could you organize the
protocol such that when a randr 1.4 composite manager is running, requests
to change to a pre-validated resolution are redirected to the composite
manager, based on something like SubstructureRedirectMask?  The composite
manager would then create a new crtc pixmap if necessary and apply the mode.
I haven't thought this through in great depth yet, or discussed with anyone
else at NVIDIA.  Error conditions might be hard to get right in particular.

Thanks,
-James

> Yeah, I hadn't thought about that, that's a mess.  GLX has a separate name for
> the pixmap, so any GLX pixmaps are still going to refer to the old pixmap.  At
> the very least, the function that frees and reallocates the new pixmap in X
> should be wrappable, so GLX can hook in and update things.  However, this
> means drivers can no longer rely on a GLX pixmap's storage not moving after it
> is created.  I think that's handleable, but it will muddy a lot of otherwise
> clean code.
> 
> I'll try to make time to look over randr 1.4 in more depth in the next couple
> of days.
> 
> Thanks,
> -James
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
> 

nvpublic