[PATCH 0/6]

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pierre Willenbrock wrote:

> Looks like xf86-video-intel does not treat allocations with format=0 the
> same with your patches. I need an extra (format !=
> 0)?format:pDraw->depth in xf86-video-intel to get kwin to work with a
> mesa forced to use DRI2GetBuffers.

D'oh.  I had intended to go back and add that, but I forgot.  Committed.

> 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?

> 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.

> Completely unrelated to this(and your patchset): i think __glXDisp_WaitX
> in xserver should call glxc->drawPriv->waitX instead of
> glxc->drawPriv->waitGL.

Committed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkn2Fz8ACgkQX1gOwKyEAw+29ACfTMBuH8yvpTQ05zFLscAffXXb
IKkAnjr1AS5XNOeVfKrsfZkzyQvx6fNf
=31jV
-----END PGP SIGNATURE-----