-----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
------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
