-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Pierre Willenbrock wrote: > Ian Romanick schrieb: >> Pierre Willenbrock wrote: >> >>> Additionally, in mesa, src/mesa/drivers/dri/intel/intel_tex_image.c, >>> intelSetTexBuffer2, color_rb[0](the front buffer) is accessed without >>> is_front_buffer_rendering being set to true, so RGBA visuals don't work >>> when doing opengl compositing. >> This is what mesa-tex_image-front-buffer.patch is about? I'm not sure I >> completely follow. Could you elaborate? > > Not all of mesa-tex_image-front-buffer.patch. I don't know if the > initialisation of is_front_buffer_rendering is needed, it seems to work > without. > > In intelSetTexBuffer2 there is this sequence: > >> intel_update_renderbuffers(pDRICtx, dPriv); >> >> rb = intel_fb->color_rb[0]; >> /* If the region isn't set, then intel_update_renderbuffers was unable >> * to get the buffers for the drawable. >> */ >> if (rb->region == NULL) >> return; > > So, it expects intel_update_renderbuffers to fill the > intel_fb->color_rb[0]->region of the dPriv. This only happens, if > is_front_buffer_rendering is true(or if there is no back buffer). Maybe > something more complex is needed, forcing is_front_buffer_rendering to > true was the easiest way to get the region allocated.
Okay, I see what's going on. This is the pixmap case. We handle this case differently on the server, so I think we just need to handle it even more differently. Right now the client only asks for the front-buffer when it's going to do front-buffer rendering. However, the server always creates the real front-buffer so that CopyRegion and friends will work. It only does this when the drawable is a window. I was under the impression that only windows had back-buffers. Is this a pixmap with a back-buffer? If so, try the attached xserver patch. I haven't tested it, but I think it should fix this problem. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkn2LdsACgkQX1gOwKyEAw8xZgCfT6aEWUid4OouXFWPpLg4aqmM d78An2R+9SeQD1C0zR+Fh5+RPXdd5KRJ =Cto9 -----END PGP SIGNATURE-----
>From a867433483fedfb0ecd8fe1eb01c010141a9ced6 Mon Sep 17 00:00:00 2001 From: Ian Romanick <[email protected]> Date: Mon, 27 Apr 2009 15:11:10 -0700 Subject: [PATCH] DRI2: Force allocation of real-front buffer for non-windows as well --- hw/xfree86/dri2/dri2.c | 19 +++++++++++-------- 1 files changed, 11 insertions(+), 8 deletions(-) diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c index 9ded048..1d49d7c 100644 --- a/hw/xfree86/dri2/dri2.c +++ b/hw/xfree86/dri2/dri2.c @@ -206,18 +206,21 @@ do_get_buffers(DrawablePtr pDraw, int *width, int *height, * attachments. The counting logic in the loop accounts for the case * where the client requests both the fake and real front-buffer. */ - if (pDraw->type == DRAWABLE_WINDOW) { - if (attachment == DRI2BufferBackLeft) { - need_real_front++; - front_format = format; - } + if (attachment == DRI2BufferBackLeft) { + need_real_front++; + front_format = format; + } - if (attachment == DRI2BufferFrontLeft) { - need_real_front--; + if (attachment == DRI2BufferFrontLeft) { + need_real_front--; + front_format = format; + + if (pDraw->type == DRAWABLE_WINDOW) { need_fake_front++; - front_format = format; } + } + if (pDraw->type == DRAWABLE_WINDOW) { if (attachment == DRI2BufferFakeFrontLeft) { need_fake_front--; have_fake_front = 1; -- 1.6.0.6
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
