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. >> Finally, i noticed that when forcing mesa to use DRI2GetBuffers, the >> front buffer is requested without considering is_front_buffer_rendering. >> In that case i get the "kwin renders to real front buffer" problem. This >> also happens in the DRI2GetBuffersWithFormat-path, when using the >> condition from the DRI2GetBuffers-path. > > That's intentional and required. With the DRI2GetBuffers path you have > to request all of the attachments that might ever be used up-front. If > a second DRI2GetBuffers call is made and the size of the drawable hasn't > changed, it will just return the same set of buffers. That is, it > won't add the newly requested buffer at all. Ah, okay. I just wanted to point out that there is still some problem with applications getting the real front buffer, and that this depends on when exactly the front buffer is requested. >[...] _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
