[PATCH 0/3] Introduce shm pool helper functions

Kristian Høgsberg hoegsberg at gmail.com
Thu Aug 9 08:56:02 PDT 2012


On Tue, Aug 07, 2012 at 02:43:35PM +0300, Ander Conselvan de Oliveira wrote:
> On 08/04/2012 04:22 PM, Andre Heider wrote:
> >This set adds a couple of helper function to wayland-client to handle
> >shm pools.
> >
> >Motivation: I noticed the amount of code duplication on client side.
> >On top of that, wayland already maintains this platform independent.
> >
> >I'm not happy with the names of the functions, and the API needs a few more
> >thoughts before declaring it public, but I wanted to get some comments about
> >this first.
> 
> I think this could be called wl_shm_mapping and we get rid of the
> unmap parameter to wl_shm_pool_helper_destroy(). In terms of a
> public API I think it is bad idea to let the user leak the mapping.
> In simple-shm.c, simple-touch.c and screenshot.c, this would be just
> a matter of keeping a reference to the mapping until it is not
> needed anymore.
> 
> >Similar to wayland-cursor, this could also be shoved into its own library.
> 
> I think this is useful enough to have it in libwayland-client, and
> as it turns out, it ends up there anyway. So there's no value in
> creating libshared. We could just have the helper implementation in
> src/ and have cursor/os-compatibility.c merged with
> src/wayland-os.c.
> 
> But anyway, let's see what Kristian thinks.

I agree that we should just put this in libwayland-client.so as public
API and then wayland-cursor and everybody else can use that.  I would
like to not try to make an allocator for the shm pool though, I think
we should just expose the mapped area and a way to create a shm buffer
given a pool, offset and size.  Also, I'm not sure about the 'helper'
in the function names...

Maybe we can just have a wl_display_create_shm_pool() helper.  We can
look up wl_shm internally and create and map the file.  We'd need a
way to get the mapping and to resize it.  Not sure about
wl_display_resize_shm_pool(), but we can't call it
wl_shm_pool_resize() either.  We could do what we do for wl_display,
and just not create dispatch stubs for any of the wl_shm interfaces
and create hand-written stubs that also does the mmap work.  That
needs a change to scanner to introduce a stubs="no" attribute to the
interface tag.

Kristian

> Cheers,
> Ander
> 
> 
> >Also see the follow up patch set for weston.
> >
> >Andre Heider (3):
> >   Introduce a static lib for shared code
> >   wayland-client: Introduce shm pool helper function
> >   wayland-cursor: Adapt to new shm pool helper functions
> >
> >  configure.ac              |    1 +
> >  cursor/Makefile.am        |   12 ++---
> >  cursor/os-compatibility.c |  128 ---------------------------------------------
> >  cursor/os-compatibility.h |   31 -----------
> >  cursor/wayland-cursor.c   |  117 +++++++++--------------------------------
> >  shared/Makefile.am        |    9 ++++
> >  shared/os-compatibility.c |  128 +++++++++++++++++++++++++++++++++++++++++++++
> >  shared/os-compatibility.h |   31 +++++++++++
> >  src/Makefile.am           |    6 ++-
> >  src/wayland-client.c      |  110 ++++++++++++++++++++++++++++++++++++++
> >  src/wayland-client.h      |   23 ++++++++
> >  11 files changed, 338 insertions(+), 258 deletions(-)
> >  delete mode 100644 cursor/os-compatibility.c
> >  delete mode 100644 cursor/os-compatibility.h
> >  create mode 100644 shared/Makefile.am
> >  create mode 100644 shared/os-compatibility.c
> >  create mode 100644 shared/os-compatibility.h
> >
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel


More information about the wayland-devel mailing list