[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