On 3/1/11 6:56 PM, "James Jones" <[email protected]> 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 > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > nvpublic _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
