Re: [PATCH weston] sdk: make C++11 plugins build again
On segunda-feira, 9 de dezembro de 2013 15:57:16, Kristian Høgsberg wrote:
> Ugh, ok, sorry. Maybe we need a private header file where we can hide
> all our C macros - ARRAY_LENGTH, static_assert, container_of etc.
This "poor man's static_assert" should work in C99 mode too:
#include
#if !defined(static_assert) && (!defined(__cplusplus) || __cplusplus < 201103L)
# define static_assert(cond, msg) enum { \
CONCAT(_static_assert_, __COUNTER__) = sizeof(char[(cond) ? 1 : -1]) \
};
#endif
For proper CONCAT defined elsewhere.
Or, for a public header:
#include
#if defined(static_assert) || (defined(__cplusplus) && __cplusplus >= 201103L)
# define wl_static_assert(cond) static_assert(cond, #cond)
#else
# define wl_static_assert(cond) enum { \
CONCAT(_static_assert_, __COUNTER__) = sizeof(char[(cond) ? 1 : -1]) \
};
#endif
For failed assertions, it will produce:
C89, C99, C++98:
error: array size is negative
C11, C++11:
error: static_assert failed "fail"
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] sdk: make C++11 plugins build again
On Mon, Dec 09, 2013 at 10:47:58PM +0100, Giulio Camuffo wrote:
> compositor.h must not define a 'static_assert' macro, since that
> conflicts with the new 'static_assert' in the standard and breaks
> the build.
Ugh, ok, sorry. Maybe we need a private header file where we can hide
all our C macros - ARRAY_LENGTH, static_assert, container_of etc.
Anyway, applied this patch for now, thanks.
Kristian
> ---
> desktop-shell/shell.c | 4
> src/compositor.h | 4
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 5f6bd6d..9fbac00 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -43,6 +43,10 @@
> #define DEFAULT_NUM_WORKSPACES 1
> #define DEFAULT_WORKSPACE_CHANGE_ANIMATION_LENGTH 200
>
> +#ifndef static_assert
> +#define static_assert(cond, msg)
> +#endif
> +
> struct focus_state {
> struct weston_seat *seat;
> struct workspace *ws;
> diff --git a/src/compositor.h b/src/compositor.h
> index ab3de19..9f34d40 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -45,10 +45,6 @@ extern "C" {
>
> #define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
>
> -#ifndef static_assert
> -#define static_assert(cond, msg)
> -#endif
> -
> #define container_of(ptr, type, member) ({ \
> const __typeof__( ((type *)0)->member ) *__mptr = (ptr);\
> (type *)( (char *)__mptr - offsetof(type,member) );})
> --
> 1.8.5.1
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Fix compilation with FreeRdp 1.1 and master
On Mon, Dec 09, 2013 at 10:16:39PM +0100, Hardening wrote: > The API to use remoteFx encoding has changed between master and stable 1.1 > branch. This patch fixes compilation for both. > Please note that the freerdp/version.h file is generated in the very last > versions > of FreeRdp so be sure to update/install the last versions. Yeah, this doesn't compile for me with an older FreeRdp because of the missing freerdp/version.h. If we're going to require a newer FreeRdp for this to compile, can we just drop the #if? Or is version.h included by freedrp.h or something so we can avoid the version.h #include? Kristian > --- > src/compositor-rdp.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c > index 8a302f8..5a2da45 100644 > --- a/src/compositor-rdp.c > +++ b/src/compositor-rdp.c > @@ -27,6 +27,7 @@ > #include > #include > > +#include > #include > #include > #include > @@ -574,7 +575,11 @@ rdp_peer_context_new(freerdp_peer* client, > RdpPeerContext* context) > context->item.peer = client; > context->item.flags = RDP_PEER_OUTPUT_ENABLED; > > +#if FREERDP_VERSION_MAJOR == 1 && FREERDP_VERSION_MINOR == 1 > context->rfx_context = rfx_context_new(); > +#else > + context->rfx_context = rfx_context_new(0); > +#endif > context->rfx_context->mode = RLGR3; > context->rfx_context->width = client->settings->DesktopWidth; > context->rfx_context->height = client->settings->DesktopHeight; > -- > 1.8.1.2 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston] compositor: add a masking mechanism to weston_layer
Giulio,
Couple thoughts. First, you don't provide an implementation of the
clipping in any of the renderers. Probably have to wait on the Collabora
people for the RPi renderer, but we should have pixman and gl
implementations of this.
Second, is there any particular reason why you're using pixman_box32_t
instead of pixman_rectangle32_t? One's as good as the other, it just seems
a little strange that there's a difference between how it's storred and the
function to set it.
More comments below.
On Dec 9, 2013 3:36 PM, "Giulio Camuffo" wrote:
>
> this adds a mechanism to mask the views belonging to a layer
> to an arbitrary rect, in the global space. The parts that don't fit
> in that rect will be clipped away.
> ---
>
> As per the discussion on IRC, masking layers is preferred to masking
views,
> so this replaces
>
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012422.html
>
> src/compositor.c | 37 -
> src/compositor.h | 9 +
> 2 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index 8f4bdef..6beea9c 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -1193,10 +1193,14 @@ weston_compositor_pick_view(struct
weston_compositor *compositor,
> wl_fixed_t *vx, wl_fixed_t *vy)
> {
> struct weston_view *view;
> +int ix = wl_fixed_to_int(x);
> +int iy = wl_fixed_to_int(y);
>
> wl_list_for_each(view, &compositor->view_list, link) {
> weston_view_from_global_fixed(view, x, y, vx, vy);
> - if (pixman_region32_contains_point(&view->surface->input,
> + if (ix >= view->layer->mask.x1 && iy >=
view->layer->mask.y1 &&
> + ix <= view->layer->mask.x2 && iy <=
view->layer->mask.y2 &&
> + pixman_region32_contains_point(&view->surface->input,
>wl_fixed_to_int(*vx),
>wl_fixed_to_int(*vy),
>NULL))
> @@ -1489,6 +1493,18 @@ view_accumulate_damage(struct weston_view *view,
> pixman_region32_union(&view->plane->damage,
> &view->plane->damage, &damage);
> pixman_region32_fini(&damage);
> +
> + /* set view->clip with the part of view->transform.boundingbox
> +* that doesn't fit into view->layer->mask, then add the opaque
region
> +* to it. We don't do the opposite, adding view->clip to opaque,
> +* because opaque is then passed to the next views, which may be
> +* in a different layer with a different mask.
> +*/
> + pixman_region32_t mask;
> + pixman_region32_init_with_extents(&mask, &view->layer->mask);
> + pixman_region32_subtract(&view->clip,
&view->transform.boundingbox, &mask);
> + pixman_region32_fini(&mask);
> +
> pixman_region32_copy(&view->clip, opaque);
> pixman_region32_union(opaque, opaque, &view->transform.opaque);
> }
> @@ -1652,6 +1668,7 @@ weston_compositor_build_view_list(struct
weston_compositor *compositor)
> wl_list_init(&compositor->view_list);
> wl_list_for_each(layer, &compositor->layer_list, link) {
> wl_list_for_each(view, &layer->view_list, layer_link) {
> + view->layer = layer;
> view_list_add(compositor, view);
I think it's probably better to have a function to add a view to a layer.
I'm not a big fan of saying view.layer may or may not be null and may not
correspond in any way to layer_link. We should keep layer and layer_link
in sync at all times.
> }
> }
> @@ -1776,11 +1793,29 @@ WL_EXPORT void
> weston_layer_init(struct weston_layer *layer, struct wl_list *below)
> {
> wl_list_init(&layer->view_list);
> + weston_layer_set_mask_infinite(layer);
> if (below != NULL)
> wl_list_insert(below, &layer->link);
> }
>
> WL_EXPORT void
> +weston_layer_set_mask(struct weston_layer *layer,
> + int x, int y, int width, int height)
> +{
> + layer->mask.x1 = x;
> + layer->mask.x2 = x + width;
> + layer->mask.y1 = y;
> + layer->mask.y2 = y + height;
> +}
> +
> +WL_EXPORT void
> +weston_layer_set_mask_infinite(struct weston_layer *layer)
> +{
> + weston_layer_set_mask(layer, INT32_MIN, INT32_MIN,
> +UINT32_MAX, UINT32_MAX);
> +}
> +
> +WL_EXPORT void
> weston_output_schedule_repaint(struct weston_output *output)
> {
> struct weston_compositor *compositor = output->compositor;
> diff --git a/src/compositor.h b/src/compositor.h
> index a161345..ab3de19 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -523,6 +523,7 @@ enum {
> struct weston_layer {
> struct wl_list view_list;
> struct wl_list link;
> +
Re: [PATCH] Add a weston_surface_set_size function
On Mon, Dec 09, 2013 at 09:16:07PM +0100, Giulio Camuffo wrote:
> 2013/12/9 Bryce W. Harrington :
> > On Wed, Dec 04, 2013 at 08:32:03PM -0600, Jason Ekstrand wrote:
> >> Surfaces that are created by clients get their size automatically updated
> >> by the attach/commit. Surfaces created directly by shells (such as black
> >> surfaces) sometimes need to be manually resized. This function allows you
> >> to do that while being somewhat less messy than messing with the internals
> >> of weston_surface manually.
> >>
> >> Signed-off-by: Jason Ekstrand
> >> ---
> >> desktop-shell/shell.c | 9 +++--
> >> src/compositor.c | 15 +++
> >> src/compositor.h | 4
> >> 3 files changed, 18 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> >> index de54e37..56e0338 100644
> >> --- a/desktop-shell/shell.c
> >> +++ b/desktop-shell/shell.c
> >> @@ -504,8 +504,7 @@ create_focus_surface(struct weston_compositor *ec,
> >> fsurf->view = weston_view_create (surface);
> >> fsurf->view->output = output;
> >>
> >> - surface->width = output->width;
> >> - surface->height = output->height;
> >> + weston_surface_set_size(surface, output->width, output->height);
> >> weston_view_set_position(fsurf->view, output->x, output->y);
> >> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
> >> pixman_region32_fini(&surface->opaque);
> >> @@ -2452,8 +2451,7 @@ create_black_surface(struct weston_compositor *ec,
> >> pixman_region32_fini(&surface->input);
> >> pixman_region32_init_rect(&surface->input, 0, 0, w, h);
> >>
> >> - surface->width = w;
> >> - surface->height = h;
> >> + weston_surface_set_size(surface, w, y);
> >> weston_view_set_position(view, x, y);
> >>
> >> return view;
> >> @@ -4585,8 +4583,7 @@ shell_fade_create_surface(struct desktop_shell
> >> *shell)
> >> return NULL;
> >> }
> >>
> >> - surface->width = 8192;
> >> - surface->height = 8192;
> >> + weston_surface_set_size(surface, 8192, 8192);
> >> weston_view_set_position(view, 0, 0);
> >> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
> >> wl_list_insert(&compositor->fade_layer.view_list,
> >> diff --git a/src/compositor.c b/src/compositor.c
> >> index 8f4bdef..97c42b3 100644
> >> --- a/src/compositor.c
> >> +++ b/src/compositor.c
> >> @@ -1133,8 +1133,7 @@ weston_surface_is_mapped(struct weston_surface
> >> *surface)
> >> }
> >>
> >> static void
> >> -weston_surface_set_size(struct weston_surface *surface,
> >> - int32_t width, int32_t height)
> >> +surface_set_size(struct weston_surface *surface, int32_t width, int32_t
> >> height)
> >
> > This is probably a stupid question so I'll apologize upfront. But is it
> > actually necessary to have a separate surface_set_size() routine from
> > weston_surface_set_size()? Couldn't the existing routine just be
> > exported for the desktop shell to use?
> >
> >> {
> >> struct weston_view *view;
> >>
> >> @@ -1148,13 +1147,21 @@ weston_surface_set_size(struct weston_surface
> >> *surface,
> >> weston_view_geometry_dirty(view);
> >> }
> >>
> >> +WL_EXPORT void
> >> +weston_surface_set_size(struct weston_surface *surface,
> >> + int32_t width, int32_t height)
> >> +{
> >> + assert(!surface->resource);
> >
> > I'm also confused why this assert is here; there isn't a deref of
> > surface->resource here or in surface_set_size(). If surface->resource
> > surface->is undefined does it trigger problems further down the stack?
>
> The thing is that surfaces which have a client side and then have a
> resource have their size set by their buffer size, and manually
> changing the width or height on them produces artifacts.
> This function is for surfaces without a client side, usually created
> by the shell.
Aha, gotcha, thanks.
Reviewed-by: Bryce Harrington
> >> + surface_set_size(surface, width, height);
> >> +}
> >> +
> >> static void
> >> weston_surface_set_size_from_buffer(struct weston_surface *surface)
> >> {
> >> int32_t width, height;
> >>
> >> if (!surface->buffer_ref.buffer) {
> >> - weston_surface_set_size(surface, 0, 0);
> >> + surface_set_size(surface, 0, 0);
> >> return;
> >> }
> >>
> >> @@ -1174,7 +1181,7 @@ weston_surface_set_size_from_buffer(struct
> >> weston_surface *surface)
> >>
> >> width = width / surface->buffer_viewport.scale;
> >> height = height / surface->buffer_viewport.scale;
> >> - weston_surface_set_size(surface, width, height);
> >> + surface_set_size(surface, width, height);
> >> }
> >>
> >> WL_EXPORT uint32_t
> >> diff --git a/src/compositor.h b/src/compositor.h
> >> index 6bd637e..9f89d00 100644
> >> --- a/src/compositor.h
> >> +++ b/src/compositor.h
> >> @@ -1138,6 +1138,10 @@ weston_view_schedule_repaint(struct weston_vi
Re: [PATCH] Add a weston_surface_set_size function
As Guilio said, we don't want shells to be randomly resizing surfaces that
come from clients. If it comes from a client, then the surface size comes
from the buffer size. If it comes from a shell, then it is free to resize
as it sees fit. I the reason for two functions is precicely that
weston_surface_set_size is only for non-client surfaces and therefore has
the assert.
--Jason Ekstrand
On Dec 9, 2013 2:16 PM, "Giulio Camuffo" wrote:
> 2013/12/9 Bryce W. Harrington :
> > On Wed, Dec 04, 2013 at 08:32:03PM -0600, Jason Ekstrand wrote:
> >> Surfaces that are created by clients get their size automatically
> updated
> >> by the attach/commit. Surfaces created directly by shells (such as
> black
> >> surfaces) sometimes need to be manually resized. This function allows
> you
> >> to do that while being somewhat less messy than messing with the
> internals
> >> of weston_surface manually.
> >>
> >> Signed-off-by: Jason Ekstrand
> >> ---
> >> desktop-shell/shell.c | 9 +++--
> >> src/compositor.c | 15 +++
> >> src/compositor.h | 4
> >> 3 files changed, 18 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> >> index de54e37..56e0338 100644
> >> --- a/desktop-shell/shell.c
> >> +++ b/desktop-shell/shell.c
> >> @@ -504,8 +504,7 @@ create_focus_surface(struct weston_compositor *ec,
> >> fsurf->view = weston_view_create (surface);
> >> fsurf->view->output = output;
> >>
> >> - surface->width = output->width;
> >> - surface->height = output->height;
> >> + weston_surface_set_size(surface, output->width, output->height);
> >> weston_view_set_position(fsurf->view, output->x, output->y);
> >> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
> >> pixman_region32_fini(&surface->opaque);
> >> @@ -2452,8 +2451,7 @@ create_black_surface(struct weston_compositor *ec,
> >> pixman_region32_fini(&surface->input);
> >> pixman_region32_init_rect(&surface->input, 0, 0, w, h);
> >>
> >> - surface->width = w;
> >> - surface->height = h;
> >> + weston_surface_set_size(surface, w, y);
> >> weston_view_set_position(view, x, y);
> >>
> >> return view;
> >> @@ -4585,8 +4583,7 @@ shell_fade_create_surface(struct desktop_shell
> *shell)
> >> return NULL;
> >> }
> >>
> >> - surface->width = 8192;
> >> - surface->height = 8192;
> >> + weston_surface_set_size(surface, 8192, 8192);
> >> weston_view_set_position(view, 0, 0);
> >> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
> >> wl_list_insert(&compositor->fade_layer.view_list,
> >> diff --git a/src/compositor.c b/src/compositor.c
> >> index 8f4bdef..97c42b3 100644
> >> --- a/src/compositor.c
> >> +++ b/src/compositor.c
> >> @@ -1133,8 +1133,7 @@ weston_surface_is_mapped(struct weston_surface
> *surface)
> >> }
> >>
> >> static void
> >> -weston_surface_set_size(struct weston_surface *surface,
> >> - int32_t width, int32_t height)
> >> +surface_set_size(struct weston_surface *surface, int32_t width,
> int32_t height)
> >
> > This is probably a stupid question so I'll apologize upfront. But is it
> > actually necessary to have a separate surface_set_size() routine from
> > weston_surface_set_size()? Couldn't the existing routine just be
> > exported for the desktop shell to use?
> >
> >> {
> >> struct weston_view *view;
> >>
> >> @@ -1148,13 +1147,21 @@ weston_surface_set_size(struct weston_surface
> *surface,
> >> weston_view_geometry_dirty(view);
> >> }
> >>
> >> +WL_EXPORT void
> >> +weston_surface_set_size(struct weston_surface *surface,
> >> + int32_t width, int32_t height)
> >> +{
> >> + assert(!surface->resource);
> >
> > I'm also confused why this assert is here; there isn't a deref of
> > surface->resource here or in surface_set_size(). If surface->resource
> > surface->is undefined does it trigger problems further down the stack?
>
> The thing is that surfaces which have a client side and then have a
> resource have their size set by their buffer size, and manually
> changing the width or height on them produces artifacts.
> This function is for surfaces without a client side, usually created
> by the shell.
>
> >
> >> + surface_set_size(surface, width, height);
> >> +}
> >> +
> >> static void
> >> weston_surface_set_size_from_buffer(struct weston_surface *surface)
> >> {
> >> int32_t width, height;
> >>
> >> if (!surface->buffer_ref.buffer) {
> >> - weston_surface_set_size(surface, 0, 0);
> >> + surface_set_size(surface, 0, 0);
> >> return;
> >> }
> >>
> >> @@ -1174,7 +1181,7 @@ weston_surface_set_size_from_buffer(struct
> weston_surface *surface)
> >>
> >> width = width / surface->buffer_viewport.scale;
> >> height = height / surface->buffer_viewport.scale;
> >> - weston_surface_set_size(surface, width,
Re: [PATCH weston] introduces a setting to give permission to any client to do screenshots
On Wed, Dec 04, 2013 at 05:38:23PM +0100, Sebastian Wick wrote:
> This patch adds a screenshooter section with the "restrict-access"
> setting which is on by default and is the current behavior of weston.
> When turning it off, all clients can use the screenshooter protocol.
> This makes screen capturing for clients easier because they don't
> have to be started by weston.
> ---
> man/weston.ini.man | 6 ++
> src/screenshooter.c | 8 +++-
> weston.ini.in | 3 +++
> 3 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/man/weston.ini.man b/man/weston.ini.man
> index 6be90bf..b94ac3d 100644
> --- a/man/weston.ini.man
> +++ b/man/weston.ini.man
> @@ -408,6 +408,12 @@ The terminal shell (string). Sets the $TERM variable.
> sets the path to the xserver to run (string).
> .RE
> .RE
> +.SH "SCREENSHOOTER SECTION"
> +.TP 7
> +.BI "restrict-access=" true
> +only allow authenticated clients to take screenshots (boolean).
> +.RE
> +.RE
> .SH "SEE ALSO"
> .BR weston (1),
> .BR weston-launch (1),
> diff --git a/src/screenshooter.c b/src/screenshooter.c
> index 0c657bc..65b6c09 100644
> --- a/src/screenshooter.c
> +++ b/src/screenshooter.c
> @@ -224,11 +224,17 @@ bind_shooter(struct wl_client *client,
> {
> struct screenshooter *shooter = data;
> struct wl_resource *resource;
> + struct weston_config_section *section;
> + int restrict_access;
>
> resource = wl_resource_create(client,
> &screenshooter_interface, 1, id);
>
> - if (client != shooter->client) {
> + section = weston_config_get_section(shooter->ec->config,
> "screenshooter", NULL, NULL);
> + weston_config_section_get_bool(section,
> + "restrict-access", &restrict_access, 1);
Could also check the return value of weston_config_section_get_bool;
it'll set errno and return -1 if the config value was typo'd or
omitted.
But does this have security implications? I assume it is restricted by
default in order to prevent clients from snooping. Could you add a bit
more detail about the specific problem(s) being solved with this? Maybe
there's a way to solve the problem without fully dropping the
restriction?
> +
> + if (restrict_access && client != shooter->client) {
> wl_resource_post_error(resource,
> WL_DISPLAY_ERROR_INVALID_OBJECT,
> "screenshooter failed: permission
> denied");
> wl_resource_destroy(resource);
> diff --git a/weston.ini.in b/weston.ini.in
> index 5181a9e..bc32567 100644
> --- a/weston.ini.in
> +++ b/weston.ini.in
> @@ -65,3 +65,6 @@ path=@libexecdir@/weston-keyboard
> #constant_accel_factor = 50
> #min_accel_factor = 0.16
> #max_accel_factor = 1.0
> +
> +#[screenshooter]
> +#restrict-access=false
Bryce
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland 2/2] doc: Fix spelling of parameters
On Mon, Dec 09, 2013 at 10:35:22PM +0100, Jonas Ådahl wrote: > Signed-off-by: Jonas Ådahl Reviewed-by: Bryce Harrington > --- > src/wayland-client.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/wayland-client.c b/src/wayland-client.c > index ab79b7b..7503ca0 100644 > --- a/src/wayland-client.c > +++ b/src/wayland-client.c > @@ -427,7 +427,7 @@ create_outgoing_proxy(struct wl_proxy *proxy, const > struct wl_message *message, > * \param proxy The proxy object > * \param opcode Opcode of the request to be sent > * \param args Extra arguments for the given request > - * \param iterface The interface to use for the new proxy > + * \param interface The interface to use for the new proxy > * > * Translates the request given by opcode and the extra arguments into the > * wire format and write it to the connection buffer. This version takes an > @@ -519,7 +519,7 @@ wl_proxy_marshal(struct wl_proxy *proxy, uint32_t opcode, > ...) > * > * \param proxy The proxy object > * \param opcode Opcode of the request to be sent > - * \param iterface The interface to use for the new proxy > + * \param interface The interface to use for the new proxy > * \param ... Extra arguments for the given request > * \return A new wl_proxy for the new_id argument or NULL on error > * > -- > 1.8.1.2 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] sdk: make C++11 plugins build again
compositor.h must not define a 'static_assert' macro, since that
conflicts with the new 'static_assert' in the standard and breaks
the build.
---
desktop-shell/shell.c | 4
src/compositor.h | 4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 5f6bd6d..9fbac00 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -43,6 +43,10 @@
#define DEFAULT_NUM_WORKSPACES 1
#define DEFAULT_WORKSPACE_CHANGE_ANIMATION_LENGTH 200
+#ifndef static_assert
+#define static_assert(cond, msg)
+#endif
+
struct focus_state {
struct weston_seat *seat;
struct workspace *ws;
diff --git a/src/compositor.h b/src/compositor.h
index ab3de19..9f34d40 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -45,10 +45,6 @@ extern "C" {
#define ARRAY_LENGTH(a) (sizeof (a) / sizeof (a)[0])
-#ifndef static_assert
-#define static_assert(cond, msg)
-#endif
-
#define container_of(ptr, type, member) ({ \
const __typeof__( ((type *)0)->member ) *__mptr = (ptr);\
(type *)( (char *)__mptr - offsetof(type,member) );})
--
1.8.5.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland 2/2] doc: Fix spelling of parameters
Signed-off-by: Jonas Ådahl --- src/wayland-client.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/wayland-client.c b/src/wayland-client.c index ab79b7b..7503ca0 100644 --- a/src/wayland-client.c +++ b/src/wayland-client.c @@ -427,7 +427,7 @@ create_outgoing_proxy(struct wl_proxy *proxy, const struct wl_message *message, * \param proxy The proxy object * \param opcode Opcode of the request to be sent * \param args Extra arguments for the given request - * \param iterface The interface to use for the new proxy + * \param interface The interface to use for the new proxy * * Translates the request given by opcode and the extra arguments into the * wire format and write it to the connection buffer. This version takes an @@ -519,7 +519,7 @@ wl_proxy_marshal(struct wl_proxy *proxy, uint32_t opcode, ...) * * \param proxy The proxy object * \param opcode Opcode of the request to be sent - * \param iterface The interface to use for the new proxy + * \param interface The interface to use for the new proxy * \param ... Extra arguments for the given request * \return A new wl_proxy for the new_id argument or NULL on error * -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor: add a masking mechanism to weston_layer
this adds a mechanism to mask the views belonging to a layer
to an arbitrary rect, in the global space. The parts that don't fit
in that rect will be clipped away.
---
As per the discussion on IRC, masking layers is preferred to masking views,
so this replaces
http://lists.freedesktop.org/archives/wayland-devel/2013-December/012422.html
src/compositor.c | 37 -
src/compositor.h | 9 +
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/src/compositor.c b/src/compositor.c
index 8f4bdef..6beea9c 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1193,10 +1193,14 @@ weston_compositor_pick_view(struct weston_compositor
*compositor,
wl_fixed_t *vx, wl_fixed_t *vy)
{
struct weston_view *view;
+int ix = wl_fixed_to_int(x);
+int iy = wl_fixed_to_int(y);
wl_list_for_each(view, &compositor->view_list, link) {
weston_view_from_global_fixed(view, x, y, vx, vy);
- if (pixman_region32_contains_point(&view->surface->input,
+ if (ix >= view->layer->mask.x1 && iy >= view->layer->mask.y1 &&
+ ix <= view->layer->mask.x2 && iy <= view->layer->mask.y2 &&
+ pixman_region32_contains_point(&view->surface->input,
wl_fixed_to_int(*vx),
wl_fixed_to_int(*vy),
NULL))
@@ -1489,6 +1493,18 @@ view_accumulate_damage(struct weston_view *view,
pixman_region32_union(&view->plane->damage,
&view->plane->damage, &damage);
pixman_region32_fini(&damage);
+
+ /* set view->clip with the part of view->transform.boundingbox
+* that doesn't fit into view->layer->mask, then add the opaque region
+* to it. We don't do the opposite, adding view->clip to opaque,
+* because opaque is then passed to the next views, which may be
+* in a different layer with a different mask.
+*/
+ pixman_region32_t mask;
+ pixman_region32_init_with_extents(&mask, &view->layer->mask);
+ pixman_region32_subtract(&view->clip, &view->transform.boundingbox,
&mask);
+ pixman_region32_fini(&mask);
+
pixman_region32_copy(&view->clip, opaque);
pixman_region32_union(opaque, opaque, &view->transform.opaque);
}
@@ -1652,6 +1668,7 @@ weston_compositor_build_view_list(struct
weston_compositor *compositor)
wl_list_init(&compositor->view_list);
wl_list_for_each(layer, &compositor->layer_list, link) {
wl_list_for_each(view, &layer->view_list, layer_link) {
+ view->layer = layer;
view_list_add(compositor, view);
}
}
@@ -1776,11 +1793,29 @@ WL_EXPORT void
weston_layer_init(struct weston_layer *layer, struct wl_list *below)
{
wl_list_init(&layer->view_list);
+ weston_layer_set_mask_infinite(layer);
if (below != NULL)
wl_list_insert(below, &layer->link);
}
WL_EXPORT void
+weston_layer_set_mask(struct weston_layer *layer,
+ int x, int y, int width, int height)
+{
+ layer->mask.x1 = x;
+ layer->mask.x2 = x + width;
+ layer->mask.y1 = y;
+ layer->mask.y2 = y + height;
+}
+
+WL_EXPORT void
+weston_layer_set_mask_infinite(struct weston_layer *layer)
+{
+ weston_layer_set_mask(layer, INT32_MIN, INT32_MIN,
+UINT32_MAX, UINT32_MAX);
+}
+
+WL_EXPORT void
weston_output_schedule_repaint(struct weston_output *output)
{
struct weston_compositor *compositor = output->compositor;
diff --git a/src/compositor.h b/src/compositor.h
index a161345..ab3de19 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -523,6 +523,7 @@ enum {
struct weston_layer {
struct wl_list view_list;
struct wl_list link;
+ pixman_box32_t mask;
};
struct weston_plane {
@@ -753,6 +754,8 @@ struct weston_view {
struct wl_list link;
struct wl_list layer_link;
struct weston_plane *plane;
+ /* layer is set when building the views list, it's not always valid! */
+ struct weston_layer *layer;
pixman_region32_t clip;
float alpha; /* part of geometry, see below */
@@ -980,6 +983,12 @@ void
weston_layer_init(struct weston_layer *layer, struct wl_list *below);
void
+weston_layer_set_mask(struct weston_layer *layer, int x, int y, int width, int
height);
+
+void
+weston_layer_set_mask_infinite(struct weston_layer *layer);
+
+void
weston_plane_init(struct weston_plane *plane,
struct weston_compositor *ec,
int32_t x, int32_t y);
--
1.8.5.1
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedeskto
[PATCH wayland 1/2] doc: Remove incorrect docmentation
The documentation was about wl_client_get_object(), not about
wl_resource_get_client().
Signed-off-by: Jonas Ådahl
---
src/wayland-server.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/src/wayland-server.c b/src/wayland-server.c
index 80e76e1..1459e09 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -592,17 +592,6 @@ wl_resource_find_for_client(struct wl_list *list, struct
wl_client *client)
return NULL;
}
-/** Look up an object in the client name space
- *
- * \param client The client object
- * \param id The object id
- * \return The object or NULL if there is not object for the given ID
- *
- * This looks up an object in the client object name space by its
- * object ID.
- *
- * \memberof wl_client
- */
WL_EXPORT struct wl_client *
wl_resource_get_client(struct wl_resource *resource)
{
--
1.8.1.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] Fix compilation with FreeRdp 1.1 and master
The API to use remoteFx encoding has changed between master and stable 1.1 branch. This patch fixes compilation for both. Please note that the freerdp/version.h file is generated in the very last versions of FreeRdp so be sure to update/install the last versions. --- src/compositor-rdp.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/compositor-rdp.c b/src/compositor-rdp.c index 8a302f8..5a2da45 100644 --- a/src/compositor-rdp.c +++ b/src/compositor-rdp.c @@ -27,6 +27,7 @@ #include #include +#include #include #include #include @@ -574,7 +575,11 @@ rdp_peer_context_new(freerdp_peer* client, RdpPeerContext* context) context->item.peer = client; context->item.flags = RDP_PEER_OUTPUT_ENABLED; +#if FREERDP_VERSION_MAJOR == 1 && FREERDP_VERSION_MINOR == 1 context->rfx_context = rfx_context_new(); +#else + context->rfx_context = rfx_context_new(0); +#endif context->rfx_context->mode = RLGR3; context->rfx_context->width = client->settings->DesktopWidth; context->rfx_context->height = client->settings->DesktopHeight; -- 1.8.1.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Add a weston_surface_set_size function
2013/12/9 Bryce W. Harrington :
> On Wed, Dec 04, 2013 at 08:32:03PM -0600, Jason Ekstrand wrote:
>> Surfaces that are created by clients get their size automatically updated
>> by the attach/commit. Surfaces created directly by shells (such as black
>> surfaces) sometimes need to be manually resized. This function allows you
>> to do that while being somewhat less messy than messing with the internals
>> of weston_surface manually.
>>
>> Signed-off-by: Jason Ekstrand
>> ---
>> desktop-shell/shell.c | 9 +++--
>> src/compositor.c | 15 +++
>> src/compositor.h | 4
>> 3 files changed, 18 insertions(+), 10 deletions(-)
>>
>> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
>> index de54e37..56e0338 100644
>> --- a/desktop-shell/shell.c
>> +++ b/desktop-shell/shell.c
>> @@ -504,8 +504,7 @@ create_focus_surface(struct weston_compositor *ec,
>> fsurf->view = weston_view_create (surface);
>> fsurf->view->output = output;
>>
>> - surface->width = output->width;
>> - surface->height = output->height;
>> + weston_surface_set_size(surface, output->width, output->height);
>> weston_view_set_position(fsurf->view, output->x, output->y);
>> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
>> pixman_region32_fini(&surface->opaque);
>> @@ -2452,8 +2451,7 @@ create_black_surface(struct weston_compositor *ec,
>> pixman_region32_fini(&surface->input);
>> pixman_region32_init_rect(&surface->input, 0, 0, w, h);
>>
>> - surface->width = w;
>> - surface->height = h;
>> + weston_surface_set_size(surface, w, y);
>> weston_view_set_position(view, x, y);
>>
>> return view;
>> @@ -4585,8 +4583,7 @@ shell_fade_create_surface(struct desktop_shell *shell)
>> return NULL;
>> }
>>
>> - surface->width = 8192;
>> - surface->height = 8192;
>> + weston_surface_set_size(surface, 8192, 8192);
>> weston_view_set_position(view, 0, 0);
>> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
>> wl_list_insert(&compositor->fade_layer.view_list,
>> diff --git a/src/compositor.c b/src/compositor.c
>> index 8f4bdef..97c42b3 100644
>> --- a/src/compositor.c
>> +++ b/src/compositor.c
>> @@ -1133,8 +1133,7 @@ weston_surface_is_mapped(struct weston_surface
>> *surface)
>> }
>>
>> static void
>> -weston_surface_set_size(struct weston_surface *surface,
>> - int32_t width, int32_t height)
>> +surface_set_size(struct weston_surface *surface, int32_t width, int32_t
>> height)
>
> This is probably a stupid question so I'll apologize upfront. But is it
> actually necessary to have a separate surface_set_size() routine from
> weston_surface_set_size()? Couldn't the existing routine just be
> exported for the desktop shell to use?
>
>> {
>> struct weston_view *view;
>>
>> @@ -1148,13 +1147,21 @@ weston_surface_set_size(struct weston_surface
>> *surface,
>> weston_view_geometry_dirty(view);
>> }
>>
>> +WL_EXPORT void
>> +weston_surface_set_size(struct weston_surface *surface,
>> + int32_t width, int32_t height)
>> +{
>> + assert(!surface->resource);
>
> I'm also confused why this assert is here; there isn't a deref of
> surface->resource here or in surface_set_size(). If surface->resource
> surface->is undefined does it trigger problems further down the stack?
The thing is that surfaces which have a client side and then have a
resource have their size set by their buffer size, and manually
changing the width or height on them produces artifacts.
This function is for surfaces without a client side, usually created
by the shell.
>
>> + surface_set_size(surface, width, height);
>> +}
>> +
>> static void
>> weston_surface_set_size_from_buffer(struct weston_surface *surface)
>> {
>> int32_t width, height;
>>
>> if (!surface->buffer_ref.buffer) {
>> - weston_surface_set_size(surface, 0, 0);
>> + surface_set_size(surface, 0, 0);
>> return;
>> }
>>
>> @@ -1174,7 +1181,7 @@ weston_surface_set_size_from_buffer(struct
>> weston_surface *surface)
>>
>> width = width / surface->buffer_viewport.scale;
>> height = height / surface->buffer_viewport.scale;
>> - weston_surface_set_size(surface, width, height);
>> + surface_set_size(surface, width, height);
>> }
>>
>> WL_EXPORT uint32_t
>> diff --git a/src/compositor.h b/src/compositor.h
>> index 6bd637e..9f89d00 100644
>> --- a/src/compositor.h
>> +++ b/src/compositor.h
>> @@ -1138,6 +1138,10 @@ weston_view_schedule_repaint(struct weston_view
>> *view);
>> int
>> weston_surface_is_mapped(struct weston_surface *surface);
>>
>> +WL_EXPORT void
>> +weston_surface_set_size(struct weston_surface *surface,
>> + int32_t width, int32_t height);
>> +
>> void
>> weston_surface_schedule_repaint(struct weston_surface *surface);
>>
>> --
>> 1.8.4.2
>>
>> _
Re: [PATCH 0/3] Test static functions
On Thu, Dec 05, 2013 at 04:38:19PM +0100, Marek Ch wrote: > Hi, > > I did similar thing like is in Weston for testing static functions. Also, I > wrote > few wl_buffer unit tests. > I appreaciate any comments :) > > P. S.: based on mailing here: > http://lists.freedesktop.org/archives/wayland-devel/2013-November/012299.html Looks good to me! I reviewed the three patches plus the docs patch. Reviewed-by: Bryce Harrington > Thanks, > Marek Ch > > > Marek Ch (3): > wayland-private: add define for testing static functions > wayland-private: move struct wl_buffer into wayland-private.h > tests: add tests for wl_buffer_* > > src/connection.c | 18 +--- > src/wayland-private.h | 24 + > tests/Makefile.am | 12 ++- > tests/buffer-test.c | 247 > ++ > 4 files changed, 286 insertions(+), 15 deletions(-) > create mode 100644 tests/buffer-test.c > > -- > 1.8.4.2 > > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Add a weston_surface_set_size function
On Wed, Dec 04, 2013 at 08:32:03PM -0600, Jason Ekstrand wrote:
> Surfaces that are created by clients get their size automatically updated
> by the attach/commit. Surfaces created directly by shells (such as black
> surfaces) sometimes need to be manually resized. This function allows you
> to do that while being somewhat less messy than messing with the internals
> of weston_surface manually.
>
> Signed-off-by: Jason Ekstrand
> ---
> desktop-shell/shell.c | 9 +++--
> src/compositor.c | 15 +++
> src/compositor.h | 4
> 3 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index de54e37..56e0338 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -504,8 +504,7 @@ create_focus_surface(struct weston_compositor *ec,
> fsurf->view = weston_view_create (surface);
> fsurf->view->output = output;
>
> - surface->width = output->width;
> - surface->height = output->height;
> + weston_surface_set_size(surface, output->width, output->height);
> weston_view_set_position(fsurf->view, output->x, output->y);
> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
> pixman_region32_fini(&surface->opaque);
> @@ -2452,8 +2451,7 @@ create_black_surface(struct weston_compositor *ec,
> pixman_region32_fini(&surface->input);
> pixman_region32_init_rect(&surface->input, 0, 0, w, h);
>
> - surface->width = w;
> - surface->height = h;
> + weston_surface_set_size(surface, w, y);
> weston_view_set_position(view, x, y);
>
> return view;
> @@ -4585,8 +4583,7 @@ shell_fade_create_surface(struct desktop_shell *shell)
> return NULL;
> }
>
> - surface->width = 8192;
> - surface->height = 8192;
> + weston_surface_set_size(surface, 8192, 8192);
> weston_view_set_position(view, 0, 0);
> weston_surface_set_color(surface, 0.0, 0.0, 0.0, 1.0);
> wl_list_insert(&compositor->fade_layer.view_list,
> diff --git a/src/compositor.c b/src/compositor.c
> index 8f4bdef..97c42b3 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -1133,8 +1133,7 @@ weston_surface_is_mapped(struct weston_surface *surface)
> }
>
> static void
> -weston_surface_set_size(struct weston_surface *surface,
> - int32_t width, int32_t height)
> +surface_set_size(struct weston_surface *surface, int32_t width, int32_t
> height)
This is probably a stupid question so I'll apologize upfront. But is it
actually necessary to have a separate surface_set_size() routine from
weston_surface_set_size()? Couldn't the existing routine just be
exported for the desktop shell to use?
> {
> struct weston_view *view;
>
> @@ -1148,13 +1147,21 @@ weston_surface_set_size(struct weston_surface
> *surface,
> weston_view_geometry_dirty(view);
> }
>
> +WL_EXPORT void
> +weston_surface_set_size(struct weston_surface *surface,
> + int32_t width, int32_t height)
> +{
> + assert(!surface->resource);
I'm also confused why this assert is here; there isn't a deref of
surface->resource here or in surface_set_size(). If surface->resource
surface->is undefined does it trigger problems further down the stack?
> + surface_set_size(surface, width, height);
> +}
> +
> static void
> weston_surface_set_size_from_buffer(struct weston_surface *surface)
> {
> int32_t width, height;
>
> if (!surface->buffer_ref.buffer) {
> - weston_surface_set_size(surface, 0, 0);
> + surface_set_size(surface, 0, 0);
> return;
> }
>
> @@ -1174,7 +1181,7 @@ weston_surface_set_size_from_buffer(struct
> weston_surface *surface)
>
> width = width / surface->buffer_viewport.scale;
> height = height / surface->buffer_viewport.scale;
> - weston_surface_set_size(surface, width, height);
> + surface_set_size(surface, width, height);
> }
>
> WL_EXPORT uint32_t
> diff --git a/src/compositor.h b/src/compositor.h
> index 6bd637e..9f89d00 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -1138,6 +1138,10 @@ weston_view_schedule_repaint(struct weston_view *view);
> int
> weston_surface_is_mapped(struct weston_surface *surface);
>
> +WL_EXPORT void
> +weston_surface_set_size(struct weston_surface *surface,
> + int32_t width, int32_t height);
> +
> void
> weston_surface_schedule_repaint(struct weston_surface *surface);
>
> --
> 1.8.4.2
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
wl_display_connect() falling back to wayland-0
Hi, I was looking at making gtk+ try the wayland backend before the x11 one [1]. This would solve the problem where every gtk+ app uses the x11 backend through XWayland when the latter is available. As you can read on comment #3 and in the patch from comment #1, wl_display_connect() currently falls back to wayland-0 if WAYLAND_DISPLAY is not in the environment, which causes the wayland backend initialization to succeed when running from X11 while weston is running (whether in a different tty or in an X11 window). The workaround I'm using in gtk+ is to directly fail the wayland backend initialization if WAYLAND_DISPLAY is not set, as Pekka suggested to me. This works nicely, making gtk+ apps use the x11 backend when launched from within X11, and use the wayland backend when started within weston. So my question is: why are we falling back to wayland-0 when WAYLAND_DISPLAY isn't set? Is this so that one can easily/quickly run apps from a tty for debugging purposes? Cheers, Emilio [1] https://bugzilla.gnome.org/show_bug.cgi?id=719989 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: The least I need to draw with OpenGL.
On Mon, 9 Dec 2013 14:15:16 +0300 Artsiom Anikeyenka wrote: > Hi, guys, > > My ultimate idea here to run a command from my terminal which will > repaint the screen and draws the cube there. I then press Ctrl+C and > get back to my terminal. So basically what I need is to create an > OpenGL context and draw to it. I want to make it the shortest way. > The less components will be used the more I like the way. > > For the whole weekend I've been trying to do that. I've been reading > wayland and weston sources but no luck yet (wayland is lacking > documentation and weston is trying to support too much stuff which > makes its code complicated). > > I think it would be really cool to have such a code somewhere because > that would be the best documentation of waylands internals. Hi, do you want to write a Wayland application, or something that runs without a window system, on the virtual console level? For a Wayland application that does not use any existing toolkit, see clients/simple-egl.c in the Weston repository. For the latter, see e.g. https://github.com/robclark/kmscube . Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
The least I need to draw with OpenGL.
Hi, guys, My ultimate idea here to run a command from my terminal which will repaint the screen and draws the cube there. I then press Ctrl+C and get back to my terminal. So basically what I need is to create an OpenGL context and draw to it. I want to make it the shortest way. The less components will be used the more I like the way. For the whole weekend I've been trying to do that. I've been reading wayland and weston sources but no luck yet (wayland is lacking documentation and weston is trying to support too much stuff which makes its code complicated). I think it would be really cool to have such a code somewhere because that would be the best documentation of waylands internals. Many thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 03/11] configure.ac: Correctly check for functions and libraries
On 09/12/2013 11:28, Ander Conselvan de Oliveira wrote:
On 12/08/2013 08:45 PM, Quentin Glidic wrote:
From: Quentin Glidic
AC_SEARCH_LIBS is preferred over AC_CHECK_FUNC and AC_CHECK_LIB
Why is it preferred?
I am trusting the Autoconf manual[1] on this one. Basically, the
double-check we are doing for dlopen is exactly what AC_SEARCH_LIBS is
done for: checking in both a library and in libC.
Signed-off-by: Quentin Glidic
---
configure.ac | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/configure.ac b/configure.ac
index 40ae145..c169311 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,9 +41,13 @@ AC_ARG_VAR([WESTON_SHELL_CLIENT],
PKG_PROG_PKG_CONFIG()
-AC_CHECK_FUNC([dlopen], [],
- AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS="-ldl"))
-AC_SUBST(DLOPEN_LIBS)
+AC_SEARCH_LIBS([dlopen], [dl])
+case "$ac_cv_search_dlopen" in
+no) AC_MSG_ERROR([dlopen support required for Weston]) ;;
+"none required") ;;
+*) DLOPEN_LIBS="$ac_cv_search_dlopen" ;;
+esac
+AC_SUBST([DLOPEN_LIBS])
AC_CHECK_DECL(SFD_CLOEXEC,[],
[AC_MSG_ERROR("SFD_CLOEXEC is needed to compile weston")],
@@ -258,13 +262,13 @@ fi
AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" = xyes)
-AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
-if test x$have_jpeglib = xyes; then
- JPEG_LIBS="-ljpeg"
-else
- AC_ERROR([libjpeg not found])
-fi
-AC_SUBST(JPEG_LIBS)
+AC_SEARCH_LIBS([jpeg_CreateDecompress], [jpeg])
+case "$ac_cv_search_pam_open_session" in
Copy & paste error, you got pam_open_session instead of
jpeg_CreateDecompress.
Oops, fixed locally.
+no) AC_MSG_ERROR([libjpeg required but not found]) ;;
+"none required") ;;
+*) JPEG_LIBS="$ac_cv_search_jpeg_CreateDecompress" ;;
+esac
+AC_SUBST([JPEG_LIBS])
Anyway, this seems like a change for the worse IMO.
Following Autotools best practices/manual is *never* worse.
> Now you're typing jpeg_CreateDecompress three times instead of just one.
8 lines for the new version vs 7 lines for the old one…
> Ideally this could be just a one-liner, since this construct has to be
repeated a few times.
It is easy enough to create a macro to do the check. If so, do we want
the error message to be accurate (e.g. Weston vs clients vs weston-launch)?
Cheers,
Ander
PKG_CHECK_MODULES(CAIRO, [cairo])
@@ -334,12 +338,13 @@ AS_IF([test "x$have_systemd_login_209" = "xyes"],
AC_ARG_ENABLE(weston-launch, [ --enable-weston-launch],,
enable_weston_launch=yes)
AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch ==
xyes)
if test x$enable_weston_launch == xyes; then
- AC_CHECK_LIB([pam], [pam_open_session], [have_pam=yes], [have_pam=no])
- if test x$have_pam == xno; then
-AC_ERROR([weston-launch requires pam])
- fi
- PAM_LIBS=-lpam
- AC_SUBST(PAM_LIBS)
+AC_SEARCH_LIBS([pam_open_session], [pam])
+case "$ac_cv_search_pam_open_session" in
+no) AC_MSG_ERROR([pam support required for weston-launch]) ;;
+"none required") ;;
+*) PAM_LIBS="$ac_cv_search_pam_open_session" ;;
+esac
+AC_SUBST([PAM_LIBS])
fi
if test x$enable_egl = xyes; then
[1]
http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf.html#Libraries
--
Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 03/11] configure.ac: Correctly check for functions and libraries
On 12/08/2013 08:45 PM, Quentin Glidic wrote:
From: Quentin Glidic
AC_SEARCH_LIBS is preferred over AC_CHECK_FUNC and AC_CHECK_LIB
Why is it preferred?
Signed-off-by: Quentin Glidic
---
configure.ac | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/configure.ac b/configure.ac
index 40ae145..c169311 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,9 +41,13 @@ AC_ARG_VAR([WESTON_SHELL_CLIENT],
PKG_PROG_PKG_CONFIG()
-AC_CHECK_FUNC([dlopen], [],
- AC_CHECK_LIB([dl], [dlopen], DLOPEN_LIBS="-ldl"))
-AC_SUBST(DLOPEN_LIBS)
+AC_SEARCH_LIBS([dlopen], [dl])
+case "$ac_cv_search_dlopen" in
+ no) AC_MSG_ERROR([dlopen support required for Weston]) ;;
+ "none required") ;;
+ *) DLOPEN_LIBS="$ac_cv_search_dlopen" ;;
+esac
+AC_SUBST([DLOPEN_LIBS])
AC_CHECK_DECL(SFD_CLOEXEC,[],
[AC_MSG_ERROR("SFD_CLOEXEC is needed to compile weston")],
@@ -258,13 +262,13 @@ fi
AM_CONDITIONAL(ENABLE_VAAPI_RECORDER, test "x$have_libva" = xyes)
-AC_CHECK_LIB([jpeg], [jpeg_CreateDecompress], have_jpeglib=yes)
-if test x$have_jpeglib = xyes; then
- JPEG_LIBS="-ljpeg"
-else
- AC_ERROR([libjpeg not found])
-fi
-AC_SUBST(JPEG_LIBS)
+AC_SEARCH_LIBS([jpeg_CreateDecompress], [jpeg])
+case "$ac_cv_search_pam_open_session" in
Copy & paste error, you got pam_open_session instead of
jpeg_CreateDecompress.
+ no) AC_MSG_ERROR([libjpeg required but not found]) ;;
+ "none required") ;;
+ *) JPEG_LIBS="$ac_cv_search_jpeg_CreateDecompress" ;;
+esac
+AC_SUBST([JPEG_LIBS])
Anyway, this seems like a change for the worse IMO. Now you're typing
jpeg_CreateDecompress three times instead of just one. Ideally this
could be just a one-liner, since this construct has to be repeated a few
times.
Cheers,
Ander
PKG_CHECK_MODULES(CAIRO, [cairo])
@@ -334,12 +338,13 @@ AS_IF([test "x$have_systemd_login_209" = "xyes"],
AC_ARG_ENABLE(weston-launch, [ --enable-weston-launch],,
enable_weston_launch=yes)
AM_CONDITIONAL(BUILD_WESTON_LAUNCH, test x$enable_weston_launch == xyes)
if test x$enable_weston_launch == xyes; then
- AC_CHECK_LIB([pam], [pam_open_session], [have_pam=yes], [have_pam=no])
- if test x$have_pam == xno; then
-AC_ERROR([weston-launch requires pam])
- fi
- PAM_LIBS=-lpam
- AC_SUBST(PAM_LIBS)
+ AC_SEARCH_LIBS([pam_open_session], [pam])
+ case "$ac_cv_search_pam_open_session" in
+ no) AC_MSG_ERROR([pam support required for weston-launch]) ;;
+ "none required") ;;
+ *) PAM_LIBS="$ac_cv_search_pam_open_session" ;;
+ esac
+ AC_SUBST([PAM_LIBS])
fi
if test x$enable_egl = xyes; then
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Add wl_dmabuf protocol
On Thu, 5 Dec 2013 18:36:38 +0100 benjamin.gaign...@linaro.org wrote: > From: Benjamin Gaignard > > It allow to use a dmabuf file descriptor in a wayland protocol. > To make as generic as possible it is up to the server to call > wl_dmabuf_send_format() and/or wl_dmabuf_send_capabilities() to signal > it capabilities. > > Signed-off-by: Benjamin Gaignard > --- > protocol/Makefile.am|6 +- > protocol/wayland-dmabuf.xml | 134 + > src/Makefile.am | 12 +- > src/wayland-dmabuf.c| 275 > +++ > src/wayland-dmabuf.h| 134 + 5 files > changed, 557 insertions(+), 4 deletions(-) create mode 100644 > protocol/wayland-dmabuf.xml create mode 100644 src/wayland-dmabuf.c > create mode 100644 src/wayland-dmabuf.h > > diff --git a/protocol/Makefile.am b/protocol/Makefile.am > index e8b6290..8c9499f 100644 > --- a/protocol/Makefile.am > +++ b/protocol/Makefile.am > @@ -1,4 +1,4 @@ > -dist_pkgdata_DATA = wayland.xml wayland.dtd > +dist_pkgdata_DATA = wayland.xml wayland-dmabuf.xml wayland.dtd > > if HAVE_XMLLINT > .PHONY: validate > @@ -6,9 +6,9 @@ if HAVE_XMLLINT > .%.xml.valid: %.xml > $(AM_V_GEN)$(XMLLINT) --noout --dtdvalid > $(srcdir)/wayland.dtd $^ > $@ > -validate: .wayland.xml.valid > +validate: .wayland.xml.valid .wayland-dmabuf.xml.valid > > all-local: validate > > -CLEANFILES = .wayland.xml.valid > +CLEANFILES = .wayland.xml.valid .wayland-dmabuf.xml.valid > endif > diff --git a/protocol/wayland-dmabuf.xml b/protocol/wayland-dmabuf.xml > new file mode 100644 > index 000..b3b7ded > --- /dev/null > +++ b/protocol/wayland-dmabuf.xml > @@ -0,0 +1,134 @@ > + > + > + > + > +Copyright © 2008-2011 Kristian Høgsberg > +Copyright © 2010-2011 Intel Corporation > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that\n the above copyright notice appear in > +all copies and that both that copyright notice and this > permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR > ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER > IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > +Bitmask of capabilities. > + > + > + > + > + > + > + > + > + > + Hi, what does the "mmap" capability bit actually mean? How is it used? I have heard that not all drivers supporting dma-buf do mmap(), but how does that reflect here? Is the mmap-capability dependent on the exporting driver only? What I mean is, if it is the Wayland client that chooses the device, and so the exporting driver, how could the Wayland server be telling the client if mmap is supported? Or does the "mmap" instead mean, that the server is able to call mmap() on dma-buf based wl_buffers? Or does it mean that the server will *always* use mmap(), and the client must provide compatible buffers? Does this protocol design work, if there are two (exporting?) gfx devices for clients to choose from, one mmap-capable and the other not? I think the intention for the mmap capability would need more documentation in the protocol. Thanks, pq ___ wayland-devel mailing list waylan
