[meta-freescale] [meta-fsl-arm][PATCH v2 5/5] gst-plugins-gl: Fix build of X11 backend
Otavio Salvador
otavio at ossystems.com.br
Fri Apr 5 04:20:58 PDT 2013
On Fri, Apr 5, 2013 at 12:21 AM, Philip Craig <phil at blackmoth.com.au> wrote:
> On Fri, Apr 5, 2013 at 1:07 PM, Otavio Salvador <otavio at ossystems.com.br> wrote:
>> On Thu, Apr 4, 2013 at 11:25 PM, Philip Craig <phil at blackmoth.com.au> wrote:
>>> On Fri, Apr 5, 2013 at 11:42 AM, Otavio Salvador
>>> <otavio at ossystems.com.br> wrote:
>>>> The X11 backend were failing to build due deprecated calls of GLib
>>>> methods; this fixes it.
>>>>
>>>> Change-Id: Iaf289bc174b45c69ef6d0c590e12daef78e65a49
>>>> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
>>>> ---
>>>> .../0002-remove-deprecated-glib-semaphores.patch | 49 ++++++++++++++++++----
>>>> .../gstreamer/gst-plugins-gl_0.10.3.bbappend | 2 +-
>>>> 2 files changed, 43 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/recipes-multimedia/gstreamer/gst-plugins-gl/0002-remove-deprecated-glib-semaphores.patch b/recipes-multimedia/gstreamer/gst-plugins-gl/0002-remove-deprecated-glib-semaphores.patch
>>>> index d50290d..36a946b 100644
>>>> --- a/recipes-multimedia/gstreamer/gst-plugins-gl/0002-remove-deprecated-glib-semaphores.patch
>>>> +++ b/recipes-multimedia/gstreamer/gst-plugins-gl/0002-remove-deprecated-glib-semaphores.patch
>>>> @@ -1,7 +1,7 @@
>>>> -From 5b7e83390bbf87e67079c1dc8fcf12b321d7b0a0 Mon Sep 17 00:00:00 2001
>>>> +From f48afb8dc3b7a89de7c72b8076b3003c320cf0a9 Mon Sep 17 00:00:00 2001
>>>> From: Jeremy Stashluk <jstashluk at dekaresearch.com>
>>>> Date: Tue, 19 Feb 2013 09:46:29 -0500
>>>> -Subject: remove deprecated glib semaphores
>>>> +Subject: [PATCH] remove deprecated glib semaphores
>>>>
>>>> glib deprecated g_{mutex|cond}_new calls since version 3.32. Replace
>>>> with the updated g_{mutex|cond}_init calls.
>>>> @@ -12,10 +12,11 @@ Upstream-Status: Pending
>>>>
>>>> Signed-off-by: Jeremy Stashluk <jstashluk at dekaresearch.com>
>>>> ---
>>>> - gst-libs/gst/gl/gstgldisplay.c | 20 +++++++++++---------
>>>> - gst-libs/gst/gl/gstglmixer.c | 5 +++--
>>>> - gst-libs/gst/gl/gstglwindow_fbES2.c | 15 +++++++++------
>>>> - 3 files changed, 23 insertions(+), 17 deletions(-)
>>>> + gst-libs/gst/gl/gstgldisplay.c | 20 +++++++++++---------
>>>> + gst-libs/gst/gl/gstglmixer.c | 5 +++--
>>>> + gst-libs/gst/gl/gstglwindow_fbES2.c | 15 +++++++++------
>>>> + gst-libs/gst/gl/gstglwindow_x11ES2.c | 10 ++++++----
>>>> + 4 files changed, 29 insertions(+), 21 deletions(-)
>>>>
>>>> diff --git a/gst-libs/gst/gl/gstgldisplay.c b/gst-libs/gst/gl/gstgldisplay.c
>>>> index a2589cb..1beac40 100644
>>>> @@ -141,6 +142,40 @@ index 57c02e1..d73cada 100644
>>>> priv->running = TRUE;
>>>> priv->allow_extra_expose_events = TRUE;
>>>>
>>>> +diff --git a/gst-libs/gst/gl/gstglwindow_x11ES2.c b/gst-libs/gst/gl/gstglwindow_x11ES2.c
>>>> +index 65afb50..814ce68 100644
>>>> +--- a/gst-libs/gst/gl/gstglwindow_x11ES2.c
>>>> ++++ b/gst-libs/gst/gl/gstglwindow_x11ES2.c
>>>> +@@ -159,14 +159,14 @@ gst_gl_window_finalize (GObject * object)
>>>> + g_debug ("display sender closed\n");
>>>> +
>>>> + if (priv->cond_send_message) {
>>>> +- g_cond_free (priv->cond_send_message);
>>>> ++ g_cond_clear (priv->cond_send_message);
>>>> + priv->cond_send_message = NULL;
>>>> + }
>>>> +
>>>> + g_mutex_unlock (priv->x_lock);
>>>> +
>>>> + if (priv->x_lock) {
>>>> +- g_mutex_free (priv->x_lock);
>>>> ++ g_mutex_clear (priv->x_lock);
>>>> + priv->x_lock = NULL;
>>>> + }
>>>> +
>>>> +@@ -329,8 +329,10 @@ gst_gl_window_new (gulong external_gl_context)
>>>> +
>>>> + setlocale (LC_NUMERIC, "C");
>>>> +
>>>> +- priv->x_lock = g_mutex_new ();
>>>> +- priv->cond_send_message = g_cond_new ();
>>>> ++ priv->x_lock = g_new (GMutex, 1);
>>>> ++ priv->cond_send_message = g_new (GCond, 1);
>>>
>>> There is no matching g_free() for the g_new(), so won't this leak
>>> memory now? It probably should embed the locks in the structure,
>>> rather than allocating them with g_new().
>>
>> According to GLib doc it does free the resouces
>> (https://developer.gnome.org/glib/2.31/glib-Threads.html#g-mutex-clear)
>
> My understanding is that g_mutex_clear() frees the resources allocated
> by g_mutex_init(), but doesn't free the memory allocated by g_new().
>
> The GLib doc talking about the deprecation suggests to statically
> allocate or embed, not to switch to using g_new()
> https://developer.gnome.org/glib/2.31/glib-Deprecated-Thread-APIs.html#g-mutex-free
It clear states an OR (statically allocated or initialized with
g_mutex_init). Checking g_mutex_init it says to use clear when not
need anymore: https://developer.gnome.org/glib/2.31/glib-Threads.html#g-mutex-init
I think it uses a reference counting to dealloc the memory. I am not
saying this is the better alternative but the eaiser with small code
change. I don't want to diverge too much from FSL code so the
maintenance work will be harder.
>>
>>>> ++ g_mutex_init (priv->x_lock);
>>>> ++ g_cond_init (priv->cond_send_message);
>>>> + priv->running = TRUE;
>>>> + priv->visible = FALSE;
>>>> + priv->parent = 0;
>>>> --
>>>> -1.7.9.5
>>>> +1.8.1
>>>>
>>>> diff --git a/recipes-multimedia/gstreamer/gst-plugins-gl_0.10.3.bbappend b/recipes-multimedia/gstreamer/gst-plugins-gl_0.10.3.bbappend
>>>> index 65257d5..20fa0a6 100644
>>>> --- a/recipes-multimedia/gstreamer/gst-plugins-gl_0.10.3.bbappend
>>>> +++ b/recipes-multimedia/gstreamer/gst-plugins-gl_0.10.3.bbappend
>>>> @@ -1,7 +1,7 @@
>>>> # gst-plugins-gl for imx6 Vivante
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>> -PRINC := "${@int(PRINC) + 2}"
>>>> +PRINC := "${@int(PRINC) + 3}"
>>>>
>>>> DEPENDS_append_mx6 = " gst-fsl-plugin gpu-viv-bin-mx6q"
>>>>
>>>> --
>>>> 1.8.1
>>>>
>>>> _______________________________________________
>>>> meta-freescale mailing list
>>>> meta-freescale at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-freescale
>>
>>
>>
>> --
>> Otavio Salvador O.S. Systems
>> E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
>> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
--
Otavio Salvador O.S. Systems
E-mail: otavio at ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
More information about the meta-freescale
mailing list