Re: [PATCH 8/8] modesetting: Add output hotplug support
On 9 December 2014 at 08:14, Aaron Plattner aplatt...@nvidia.com wrote: On 12/08/2014 01:01 AM, Daniel Martin wrote: On 5 December 2014 at 17:45, Keith Packard kei...@keithp.com wrote: Daniel Martin daniel.mar...@secunet.com writes: From: Daniel Martin consume.no...@gmail.com When receiving a hotplug uevent, check if we have to add or remove outputs and act accordingly. Signed-off-by: Daniel Martin consume.no...@gmail.com --- With this patch we create or destroy outputs as a reaction to uevents. Due to my limited experience, the solution is either total crap, cause I'm doing it wrong, or it is that complicated, cause the server never had disappearing outputs in mind, or a combination of both. Both of these patches look awesome; RandR and the xf86 code is all designed to support output/crtc hot-plugging, but we've never had a driver that did it. The intel driver does it. That's where I borrowed the functional ideas. I've reviewed the code, and it looks correct. As it's essentially new functionality, it would normally wait until after 1.17 anyways, but in this case, we should wait until we have some way of testing it before merging it in. I have an idea how one could test this on none-MST hw: add/remove the outputs depending on their connection state. So, you would just see connected ones. For 7/8 and 8/8 in this series: Reviewed-by: Keith Packard kei...@keithp.com Thanks. Then I'll just move the log message in patch 8 and leave the hunk where it is. v2 with the update for patch 6 and 8, and the patch to test the (fake) output hotplug should arrive later this day. Be careful with deleting outputs. The NVIDIA driver did this with MST devices when we first implemented them and it really confused gnome-settings-daemon. In general, RandR clients don't have a good way of avoiding a BadMatch protocol error if an output they're talking about goes away -- the timestamp mechanism doesn't protect against the actual XID disappearing. We fixed the problem by just leaving outputs around forever and in practice, stale MST outputs aren't a big deal, especially since they get reused if the same MST topology reappears later. Hmm, the awesome Xlib error handling ... Keith, what do you think, should I change the patch to keep the outputs? In case, I have to admin, that I can't manage to do this during this week. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] saa: Adapt to GC client clip changes in xserver 1.17
On Thu, 2014-12-04 at 10:35 -0500, Adam Jackson wrote: 1.17 always stores the client clip as a region, so there's no longer a clientClipType member to look at. Change the code to just inspect whether the clientClip is non-null, since that works both before and after 1.17. Ping? This is required to make vmware build against 1.17. Is there a better place to send this? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL] GLX and Xephyr fixes
The following changes since commit c1455f76c6b1aa4ecaacb2221a687244285aa44b: glx: Add implementation of __GLXContext-loseCurrent for direct ctxts (2014-12-09 14:15:55 -0800) are available in the git repository at: ssh://people.freedesktop.org/~ajax/xserver.git xserver-next for you to fetch changes up to e774663fa5209ff469d920821934bb1f5964a72f: ephyr: Implement per-screen colormaps (2014-12-10 11:04:09 -0500) Adam Jackson (2): glx: Dynamically compute attribute slot in GetDrawableAttributes glx: Add hack for GLX-1.2-style naked windows to GetDrawableAttributes Michele Baldessari (1): ephyr: Implement per-screen colormaps glx/glxcmds.c | 71 - hw/kdrive/ephyr/ephyr.c | 2 +- hw/kdrive/ephyr/ephyr.h | 1 + hw/kdrive/ephyr/hostx.c | 11 hw/kdrive/ephyr/hostx.h | 2 +- 5 files changed, 50 insertions(+), 37 deletions(-) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] saa: Adapt to GC client clip changes in xserver 1.17
Hi, Sorry for the late response. Best is to send to linux-graphics-maintai...@vmware.com as listed in the xorg maintainer info. The change looks good to me. I just need to run it through our compile-testing-tool Thanks! /Thomas On 12/10/2014 05:05 PM, Adam Jackson wrote: On Thu, 2014-12-04 at 10:35 -0500, Adam Jackson wrote: 1.17 always stores the client clip as a region, so there's no longer a clientClipType member to look at. Change the code to just inspect whether the clientClip is non-null, since that works both before and after 1.17. Ping? This is required to make vmware build against 1.17. Is there a better place to send this? - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.x.org_archives_xorg-2Ddeveld=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEAm=Vblj9nl7sXI_SxKc-tgxVBsBre5FOAOECu5-bFw__90s=jh1CE-HFGJ9DMEqPYMLErQRnql4OjPQuFjxbtHtHvq8e= Info: https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.x.org_mailman_listinfo_xorg-2Ddeveld=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEAm=Vblj9nl7sXI_SxKc-tgxVBsBre5FOAOECu5-bFw__90s=WrqV4SFuS4EgzJwWIvRKFXOPkidMvhIy_tkUaHi6vgIe= ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 8/8] modesetting: Add output hotplug support
On Wed, Dec 10, 2014 at 3:03 AM, Daniel Martin consume.no...@gmail.com wrote: On 9 December 2014 at 08:14, Aaron Plattner aplatt...@nvidia.com wrote: On 12/08/2014 01:01 AM, Daniel Martin wrote: On 5 December 2014 at 17:45, Keith Packard kei...@keithp.com wrote: Daniel Martin daniel.mar...@secunet.com writes: From: Daniel Martin consume.no...@gmail.com When receiving a hotplug uevent, check if we have to add or remove outputs and act accordingly. Signed-off-by: Daniel Martin consume.no...@gmail.com --- With this patch we create or destroy outputs as a reaction to uevents. Due to my limited experience, the solution is either total crap, cause I'm doing it wrong, or it is that complicated, cause the server never had disappearing outputs in mind, or a combination of both. Both of these patches look awesome; RandR and the xf86 code is all designed to support output/crtc hot-plugging, but we've never had a driver that did it. The intel driver does it. That's where I borrowed the functional ideas. I've reviewed the code, and it looks correct. As it's essentially new functionality, it would normally wait until after 1.17 anyways, but in this case, we should wait until we have some way of testing it before merging it in. I have an idea how one could test this on none-MST hw: add/remove the outputs depending on their connection state. So, you would just see connected ones. For 7/8 and 8/8 in this series: Reviewed-by: Keith Packard kei...@keithp.com Thanks. Then I'll just move the log message in patch 8 and leave the hunk where it is. v2 with the update for patch 6 and 8, and the patch to test the (fake) output hotplug should arrive later this day. Be careful with deleting outputs. The NVIDIA driver did this with MST devices when we first implemented them and it really confused gnome-settings-daemon. In general, RandR clients don't have a good way of avoiding a BadMatch protocol error if an output they're talking about goes away -- the timestamp mechanism doesn't protect against the actual XID disappearing. We fixed the problem by just leaving outputs around forever and in practice, stale MST outputs aren't a big deal, especially since they get reused if the same MST topology reappears later. Hmm, the awesome Xlib error handling ... Keith, what do you think, should I change the patch to keep the outputs? In case, I have to admin, that I can't manage to do this during this week. IIRC, Dave added a driver option for radeon and intel to pick if you want to keep them or not. Alex ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 8/8] modesetting: Add output hotplug support
Daniel Martin consume.no...@gmail.com writes: Hmm, the awesome Xlib error handling ... Keith, what do you think, should I change the patch to keep the outputs? In case, I have to admin, that I can't manage to do this during this week. No, we don't need to work around client bugs like that. -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 8/8] modesetting: Add output hotplug support
On 12/10/2014 09:29 AM, Keith Packard wrote: Daniel Martin consume.no...@gmail.com writes: Hmm, the awesome Xlib error handling ... Keith, what do you think, should I change the patch to keep the outputs? In case, I have to admin, that I can't manage to do this during this week. No, we don't need to work around client bugs like that. How is a client expected to deal with outputs going away? XSync() and wire up an error handler around all of its RandR calls? If so, that sucks. -- Aaron ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 8/8] modesetting: Add output hotplug support
Aaron Plattner aplatt...@nvidia.com writes: How is a client expected to deal with outputs going away? XSync() and wire up an error handler around all of its RandR calls? If so, that sucks. Like any client deals with any resource which may disappear. Xlib's error handling is pretty painful, but it can be made to mostly work. xcb makes it a lot easier... -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 8/8] modesetting: Add output hotplug support
On 12/10/2014 10:17 AM, Keith Packard wrote: Aaron Plattner aplatt...@nvidia.com writes: How is a client expected to deal with outputs going away? XSync() and wire up an error handler around all of its RandR calls? If so, that sucks. Like any client deals with any resource which may disappear. Xlib's error handling is pretty painful, but it can be made to mostly work. xcb makes it a lot easier... Fair enough. -- Aaron ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: DRI3/Present fixes for XServers 1.16 and 1.17rc - reviewed
On Sat, Dec 6, 2014 at 05:40:06 +0100, Mario Kleiner wrote: Ok, the final patchset. I made the changes Eric Anholt proposed, retested, and got them reviewed by him. With those on top of XServer 1.16.2, DRI3/Present works for me on all drivers and backends (intel sna, uxa and nouveau exa, glamor), single and dual-display fullscreen and windowed, with/without compositor, vsynced or non-vsynced etc. The patches apply cleanly to master, 1.17-rc and 1.16.2. Forgot to reply yesterday... they didn't apply on their own on top of 1.16.2, but, with the other patch you mentioned, cherry-picked and released as part of 1.16.2.901. Thanks, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] dix: offset touch root coordinates by ScreenRec origins (#86655)
For two ScreenRecs abs pointer positioning was working fine, but touch events stuck to the lower/right edge on any screen but the one with a 0/0 origin. Cause is a missing offset by the screen coordinates, causing the root coordinates in the event to desktop-wide, not screen-wide. Offset properly, just like we do for pointer events. X.Org Bug 86655 http://bugs.freedesktop.org/show_bug.cgi?id=86655 Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- dix/getevents.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dix/getevents.c b/dix/getevents.c index dd96265..6684ddc 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -2044,7 +2044,7 @@ GetTouchEvents(InternalEvent *events, DeviceIntPtr dev, uint32_t ddx_touchid, event-root = scr-root-drawable.id; -event_set_root_coordinates(event, screenx, screeny); +event_set_root_coordinates(event, screenx - scr-x, screeny - scr-y); event-touchid = client_id; event-flags = flags; -- 2.1.0 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
xinitrc empty variables (xterm/xclock/twm) on config file
HI I am very new on Xorg and X11 technology, but I think there is a problem with the xinit system, here is the story : When I compiled the xinit from the source code with these options on the configure: ./configure --without-twm --without-xclock --without-xterm Everything works fine , but at the end the file xinitrc in /etc/X11/xinit/xinitrc -no -no -geometry 50x50-1+1 -no -geometry 80x50+494+51 -no -geometry 80x20+494-0 -exec no -geometry 80x66+0+0 -name login Usually the output without these options is : -TWM -XCLOCK -geometry 50x50-1+1 -XTERM -geometry 80x50+494+51 -XTERM -geometry 80x20+494-0 -exec XTERM -geometry 80x66+0+0 -name login I was checking the xinitrc.cpp and discover that these are global variables and at some point on the configure.ac there is that problem( instead of no -geometry the line should be deleted). If this is a bug I am more than happy to try to fix it.( or if I am calling it wrong please tell me ) I did a personal patch , but is not the clean way to fix it . Something like: [ -x /usr/bin/startxfce4 ] /usr/bin/startxfce4 Same for xclock and xterm All the feedback is more than welcome Regards Victor Rodriguez ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glamor: Reinstate glamor_(egl_)destroy_textured_pixmap
On 10.12.2014 16:21, Michel Dänzer wrote: From: Michel Dänzer michel.daen...@amd.com They are part of the ABI. This probably fixes https://bugs.freedesktop.org/show_bug.cgi?id=87198 . -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glamor: Reinstate glamor_(egl_)destroy_textured_pixmap
Michel Dänzer mic...@daenzer.net writes: From: Michel Dänzer michel.daen...@amd.com They are part of the ABI. Sorry for breaking the ABI. No biscuit for me today. Reviewed-by: Keith Packard kei...@keithp.com Merged. c1455f7..91651e7 master - master We should revert this after 1.17 as there's no reason to expose this API at this point. Just having the driver call glamor_destroy_pixmap should always suffice. -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] GLX and Xephyr fixes
Adam Jackson a...@nwnk.net writes: Adam Jackson (2): glx: Dynamically compute attribute slot in GetDrawableAttributes glx: Add hack for GLX-1.2-style naked windows to GetDrawableAttributes This one is a bug fix, but the other two look like new features? Do you think I should merge them all for 1.17? Michele Baldessari (1): ephyr: Implement per-screen colormaps -- keith.pack...@intel.com signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/4] glamor: Make glamor_destroy_textured_pixmap idempotent
From: Michel Dänzer michel.daen...@amd.com For robustness against drivers which may call both glamor_(egl_)destroy_textured_pixmap and glamor_destroy_pixmap. Signed-off-by: Michel Dänzer michel.daen...@amd.com --- glamor/glamor.c | 1 + glamor/glamor_fbo.c | 2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/glamor/glamor.c b/glamor/glamor.c index cbd0e02..d1aa1cf 100644 --- a/glamor/glamor.c +++ b/glamor/glamor.c @@ -226,6 +226,7 @@ glamor_destroy_textured_pixmap(PixmapPtr pixmap) glamor_egl_destroy_pixmap_image(pixmap); #endif glamor_pixmap_destroy_fbo(pixmap_priv); +glamor_set_pixmap_private(pixmap, NULL); } } } diff --git a/glamor/glamor_fbo.c b/glamor/glamor_fbo.c index 4273826..d2aabb2 100644 --- a/glamor/glamor_fbo.c +++ b/glamor/glamor_fbo.c @@ -540,8 +540,6 @@ glamor_pixmap_destroy_fbo(glamor_pixmap_private *priv) if (fbo) glamor_destroy_fbo(fbo); } - -free(priv); } Bool -- 2.1.3 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/4] glamor: Make glamor_set_pixmap_private not crash if the pixmap has no fbo
From: Michel Dänzer michel.daen...@amd.com
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
glamor/glamor.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index c4f3f3a..cbd0e02 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -563,8 +563,11 @@ glamor_set_pixmap_private(PixmapPtr pixmap,
glamor_pixmap_private *priv)
else {
if (old_priv == NULL)
return;
-fbo = glamor_pixmap_detach_fbo(old_priv);
-glamor_purge_fbo(fbo);
+
+if (old_priv-base.fbo) {
+fbo = glamor_pixmap_detach_fbo(old_priv);
+glamor_purge_fbo(fbo);
+}
free(old_priv);
}
--
2.1.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/4] glamor: Make sure glamor_egl_close_screen wraps glamor_close_screen
From: Michel Dänzer michel.daen...@amd.com
The other way around fails to destroy the screen pixmap EGL image:
==1782== 80 (32 direct, 48 indirect) bytes in 1 blocks are definitely lost in
loss record 981 of 2,171
==1782==at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==1782==by 0xF9D4BD2: dri2_create_image_from_dri (egl_dri2.c:1264)
==1782==by 0xF9D4BD2: dri2_create_image_dma_buf (egl_dri2.c:1764)
==1782==by 0xF9D4BD2: dri2_create_image_khr (egl_dri2.c:1798)
==1782==by 0xF9C7937: eglCreateImageKHR (eglapi.c:1494)
==1782==by 0x85D5655: _glamor_egl_create_image (glamor_egl.c:134)
==1782==by 0x85D5655: glamor_egl_create_textured_pixmap (glamor_egl.c:302)
==1782==by 0x85D579B: glamor_egl_create_textured_screen (glamor_egl.c:225)
==1782==by 0xC1BE05D: radeon_glamor_create_screen_resources
(radeon_glamor.c:67)
==1782==by 0xC1B6153: RADEONCreateScreenResources_KMS (radeon_kms.c:258)
==1782==by 0x4B2105: xf86CrtcCreateScreenResources (xf86Crtc.c:709)
==1782==by 0x43C823: dix_main (main.c:223)
==1782==by 0x6CFAB44: (below main) (libc-start.c:287)
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
glamor/glamor.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index d1aa1cf..e6e8647 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -424,6 +424,9 @@ glamor_init(ScreenPtr screen, unsigned int flags)
glamor_set_debug_level(glamor_debug_level);
+glamor_priv-saved_procs.close_screen = screen-CloseScreen;
+screen-CloseScreen = glamor_close_screen;
+
/* If we are using egl screen, call egl screen init to
* register correct close screen function. */
if (flags GLAMOR_USE_EGL_SCREEN) {
@@ -433,9 +436,6 @@ glamor_init(ScreenPtr screen, unsigned int flags)
goto fail;
}
-glamor_priv-saved_procs.close_screen = screen-CloseScreen;
-screen-CloseScreen = glamor_close_screen;
-
glamor_priv-saved_procs.create_screen_resources =
screen-CreateScreenResources;
screen-CreateScreenResources = glamor_create_screen_resources;
--
2.1.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/4] glamor: Fix use-after-free in glamor_destroy_textured_pixmap
From: Michel Dänzer michel.daen...@amd.com
==25551== Invalid read of size 8
==25551==at 0x85D5F2C: glamor_egl_destroy_pixmap_image (glamor_egl.c:527)
==25551==by 0x85D7750: glamor_destroy_pixmap (glamor.c:235)
==25551==by 0xC1BDD9B: radeon_glamor_destroy_pixmap (radeon_glamor.c:278)
==25551==by 0x5098F6: FreePicture (picture.c:1425)
==25551==by 0x85DD7A9: glamor_unrealize_glyph_caches (glamor_glyphs.c:257)
==25551==by 0x85D7B50: glamor_close_screen (glamor.c:586)
==25551==by 0x4B1A82: xf86CrtcCloseScreen (xf86Crtc.c:734)
==25551==by 0x4CFFC7: CursorCloseScreen (cursor.c:187)
==25551==by 0x513A44: AnimCurCloseScreen (animcur.c:106)
==25551==by 0x51529B: present_close_screen (present_screen.c:64)
==25551==by 0x43CA83: dix_main (main.c:351)
==25551==by 0x6CFAB44: (below main) (libc-start.c:287)
==25551== Address 0x83dafa0 is 96 bytes inside a block of size 152 free'd
==25551==at 0x4C29E90: free (vg_replace_malloc.c:473)
==25551==by 0x85D76B4: glamor_destroy_textured_pixmap (glamor.c:225)
==25551==by 0x85D7750: glamor_destroy_pixmap (glamor.c:235)
==25551==by 0xC1BDD9B: radeon_glamor_destroy_pixmap (radeon_glamor.c:278)
==25551==by 0x5098F6: FreePicture (picture.c:1425)
==25551==by 0x85DD7A9: glamor_unrealize_glyph_caches (glamor_glyphs.c:257)
==25551==by 0x85D7B50: glamor_close_screen (glamor.c:586)
==25551==by 0x4B1A82: xf86CrtcCloseScreen (xf86Crtc.c:734)
==25551==by 0x4CFFC7: CursorCloseScreen (cursor.c:187)
==25551==by 0x513A44: AnimCurCloseScreen (animcur.c:106)
==25551==by 0x51529B: present_close_screen (present_screen.c:64)
==25551==by 0x43CA83: dix_main (main.c:351)
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
glamor/glamor.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index b32cc16..c4f3f3a 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -221,11 +221,12 @@ glamor_destroy_textured_pixmap(PixmapPtr pixmap)
{
if (pixmap-refcnt == 1) {
glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap);
-if (pixmap_priv != NULL)
-glamor_pixmap_destroy_fbo(pixmap_priv);
+if (pixmap_priv != NULL) {
#if GLAMOR_HAS_GBM
-glamor_egl_destroy_pixmap_image(pixmap);
+glamor_egl_destroy_pixmap_image(pixmap);
#endif
+glamor_pixmap_destroy_fbo(pixmap_priv);
+}
}
}
--
2.1.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
