glamor: Ask the server to always allocate our private.

This avoids a lot of screwing around to attach our privates later.  It
means that non-glamor pixmaps now gain 120 bytes of glamor privates on
64-bit (which has quite a bit of fixable bloat), and glamor pixmaps
take one less pointer of storage (not counting malloc overhead).

Note that privates start out zero-filled, which matches the callocs we
were doing when making our own privates, and in the case of an fb
pixmap that has a priv where it didn't before, the type ends up being
GLAMOR_MEMORY as we would want.

v2: Clarify that the GLAMOR_MEMORY enum must be 0 (as it was
    previosuly), so that the new pixmap private behavior is as
    expected.  Suggested by keithp.

Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> (v1)
Reviewed-by: Keith Packard <keithp@keithp.com>

1 files changed, 4 insertions, 2 deletions

diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c
index 84f3b22b0..1eee304ed 100644
--- a/glamor/glamor_fbo.c
+++ b/glamor/glamor_fbo.c
@@ -471,9 +471,11 @@ glamor_pixmap_attach_fbo(PixmapPtr pixmap, glamor_pixmap_fbo *fbo)
 }
 
 void
-glamor_pixmap_destroy_fbo(glamor_screen_private *glamor_priv,
-                          glamor_pixmap_private *priv)
+glamor_pixmap_destroy_fbo(PixmapPtr pixmap)
 {
+    ScreenPtr screen = pixmap->drawable.pScreen;
+    glamor_screen_private *glamor_priv = glamor_get_screen_private(screen);
+    glamor_pixmap_private *priv = glamor_get_pixmap_private(pixmap);
     glamor_pixmap_fbo *fbo;
 
     if (glamor_pixmap_priv_is_large(priv)) {