libinput - Wacom Intuos PT S 2 Finger

[g]

Hello, I've just received the tablet mentioned above. I've tried to get
it up and running with libinput-gestures. When starting gestures I get
the following error:

libinput error: libinput bug: Device 'Wacom Intuos PT S 2 Pad' does not
meet tablet criteria. Ignoring this device.

I guess it's just unknown to libinput. If somebody can point me to the
right place in code I will submit a patch.

Regards
Goran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v2] compositor-drm: pageflip timeout implementation

[Pekka Paalanen]

On Tue, 28 Feb 2017 18:35:11 +
Emmanuel Gil Peyrot  wrote:

> Weston will not repaint until previous update has been acked by a
> pageflip event coming from the drm driver. However, some buggy drivers
> won’t return those events or will stop sending them at some point and
> Weston output repaints will completely freeze. To ease developers’ task
> in testing their drivers, this patch makes compositor-drm use a timer
> to detect cases where those pageflip events stop coming.
> 
> This timeout implementation is software only and includes basic
> features usually found in a watchdog. We simply exit Weston gracefully
> with a log message and an exit code when the timout is reached.
> 
> The timeout value can be set via weston.ini by adding a
> pageflip-timeout= entry under a new [compositor-drm]
> section. Setting it to 0 disables the timeout feature.
> 
> v2:
> - Made sure we would get both the pageflip and the vblank events before
>   stopping the timer.
> - Reordered the error and success cases in
>   drm_output_pageflip_timer_create() to be more in line with the rest
>   of the code.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=83884
> Signed-off-by: Frederic Plourde 
> Signed-off-by: Emmanuel Gil Peyrot 
> ---
>  compositor/main.c  |  2 ++
>  libweston/compositor-drm.c | 64 
> ++
>  libweston/compositor-drm.h |  7 +
>  man/weston.ini.man |  5 
>  4 files changed, 78 insertions(+)
> 

Hi,

there are some details to fix, but looking good overall.

> diff --git a/compositor/main.c b/compositor/main.c
> index 72c3cd10..e870dd4a 100644
> --- a/compositor/main.c
> +++ b/compositor/main.c
> @@ -1235,6 +1235,8 @@ load_drm_backend(struct weston_compositor *c,
>   weston_config_section_get_string(section,
>"gbm-format", _format,
>NULL);
> + weston_config_section_get_uint(section, "pageflip-timeout",
> +_timeout, 0);
>  
>   config.base.struct_version = WESTON_DRM_BACKEND_CONFIG_VERSION;
>   config.base.struct_size = sizeof(struct weston_drm_backend_config);
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 7f78699c..e85ebab8 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -119,6 +119,7 @@ struct drm_backend {
>   int32_t cursor_height;
>  
>   uint32_t connector;
> + uint32_t pageflip_timeout;
>  };
>  
>  struct drm_mode {
> @@ -182,6 +183,8 @@ struct drm_output {
>  
>   struct vaapi_recorder *recorder;
>   struct wl_listener recorder_frame_listener;
> +
> + struct wl_event_source *pageflip_timer;
>  };
>  
>  /*
> @@ -225,6 +228,44 @@ to_drm_backend(struct weston_compositor *base)
>   return container_of(base->backend, struct drm_backend, base);
>  }
>  
> +static int
> +pageflip_timeout(void *data) {
> + /*
> +  * Our timer just went off, that means we're not receiving drm
> +  * page flip events anymore for that output. Let's gracefully exit
> +  * weston with a return value so devs can debug what's going on.
> +  */
> + struct drm_output *output = data;
> + struct weston_compositor *compositor = output->base.compositor;
> +
> + weston_log("Pageflip timeout reached, your driver is probably "
> +"buggy!  Exiting.\n");

While at it, you might print the output name here.

> + weston_compositor_exit_with_code(compositor, EXIT_FAILURE);
> +
> + return -1;

pageflip_timeout() is a timer callback, which is a libwayland-server
event loop dispatch vfunc. Returning -1 here might theoretically
confuse other dispatch vfuncs called from wl_event_loop_dispatch()'s
post_dispatch_check() phase. The post_dispatch_check() is intended to
loop until all dispatch funcs return zero.

However, a source must be explicitly marked to be processed in
post_dispatch_check() by calling wl_event_source_check(), and we don't
do that for timers in Weston. While it is harmless to return -1 in this
case, I would like to see the return value to be 0 to denote there is
no post-check needed.

> +}
> +
> +/* Creates the pageflip timer. Note that it isn't armed by default */
> +static int
> +drm_output_pageflip_timer_create(struct drm_output *output)
> +{
> + struct wl_event_loop *loop = NULL;
> + struct weston_compositor *ec = output->base.compositor;
> +
> + loop = wl_display_get_event_loop(ec->wl_display);
> + assert(loop);
> + output->pageflip_timer = wl_event_loop_add_timer(loop,
> +  pageflip_timeout,
> +  output);
> +
> + if (output->pageflip_timer == NULL) {
> + weston_log("creating drm pageflip timer failed: %m\n");
> + return -1;
> + }
> +
> + return 0;
> +}
> +
>  

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Olivier Fourdan]

Hi Jonas,

> > > I would prefer leaning towards just making the compositors more
> > > considerate about their Xwayland configuration. I believe the global
> > > trend is to move towards the compositor having all the configurability
> > > in itself, and all the other components having a single source of
> > > configuration in the running system: the compositor. I would compare
> > > Xwayland to libinput here.
> > 
> > Yes, but that means that all compositors need to have this
> > "configurability", even though it's actually Xwayland that uses it.
> > 
> 
> For a compositor that supports respawning Xwayland, to be able to change
> the Xwayland configurations without restarting the actual compositor
> would still need this "configurability", as any user set environment
> variable will be static for the whole session.

Obviously, with a compositor able to survive respawning Xwayland, adapting the 
Xwayland command line options dynamically when it detects a crash in Xwayland, 
the use of environment variable is a lot less attractive.

But I am not aware of any compositor able to do that (and given how mutter is 
dependent on X even on Wayland, I would not expect such a mechanism to be 
available in gnome-shell any time soon).

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Jonas Ådahl]

On Thu, Mar 02, 2017 at 05:47:10AM -0500, Olivier Fourdan wrote:
> Hi Pekka,
> 
> > I understand the attractiveness of adding an override, bypassing the
> > compositors like this. But, essentially it is just that: a
> > configuration bypass.
> 
> True.
>  
> > I would prefer leaning towards just making the compositors more
> > considerate about their Xwayland configuration. I believe the global
> > trend is to move towards the compositor having all the configurability
> > in itself, and all the other components having a single source of
> > configuration in the running system: the compositor. I would compare
> > Xwayland to libinput here.
> 
> Yes, but that means that all compositors need to have this "configurability", 
> even though it's actually Xwayland that uses it.
> 

For a compositor that supports respawning Xwayland, to be able to change
the Xwayland configurations without restarting the actual compositor
would still need this "configurability", as any user set environment
variable will be static for the whole session.


Jonas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Pekka Paalanen]

On Thu, 2 Mar 2017 05:47:10 -0500 (EST)
Olivier Fourdan  wrote:

> Hi Pekka,
> 
> > I understand the attractiveness of adding an override, bypassing the
> > compositors like this. But, essentially it is just that: a
> > configuration bypass.  
> 
> True.
>  
> > I would prefer leaning towards just making the compositors more
> > considerate about their Xwayland configuration. I believe the global
> > trend is to move towards the compositor having all the configurability
> > in itself, and all the other components having a single source of
> > configuration in the running system: the compositor. I would compare
> > Xwayland to libinput here.  
> 
> Yes, but that means that all compositors need to have this
> "configurability", even though it's actually Xwayland that uses it.

Indeed, the same arguments as with libinput.

> > Xwayland is not a program launched manually, but Xephyr is, isn't
> > it? That makes an env var very convenient with Xephyr, less so with
> > Xwayland.  
> 
> I have seen glamor issues with Xwayland that do not show up in
> Xephyr, we cannot always use Xephyr to investigate glamor issues (or
> the underlying layers),
> https://bugs.freedesktop.org/show_bug.cgi?id=99400 is one of them...

I meant that "Xephyr uses env vars, Xwayland should too" was not exactly
a good justification to add any env vars to Xwayland due to how
Xwayland vs. Xephyr get launched.

> > Are there already other env vars useful with Xwayland (debugging)?  
> 
> Not that I am aware, except GLAMOR_DEBUG.

That's a precedent, at least.

> > This is just food for thought, I don't want to NAK this patch just
> > by my own opinion.  
> 
> Yeap, I appreciate your views and share most of them, I am not a big
> fan of environment variables for such purpose either (that's why I
> sent this patch as an RFC), but I've felt many times that frustration
> of not being able to tell simply to a user to try Xwayland without
> glamor...

Yes, I understand.

I wonder if you'd like to have more toggles in your Wayland stack,
though, e.g. disable certain aspects of hw-accel or hw-accel completely
in the compositor too. Like Weston/DRM has --use-pixman which
consequently causes Xwayland to fall back from GLAMOR. But you probably
use LIBGL_ALWAYS_SOFTWARE or something for that, right?

What about GLAMOR with software-GL? Or forcing GLAMOR to use a GL
flavour it normally would not pick because another one more suitable is
available? I suppose those would be controlled via Mesa env vars, but
then how do you set them only for Xwayland so they don't affect your
compositor too?


Thanks,
pq


pgpokFB9IzUsV.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Olivier Fourdan]

Hi Pekka,

> I understand the attractiveness of adding an override, bypassing the
> compositors like this. But, essentially it is just that: a
> configuration bypass.

True.
 
> I would prefer leaning towards just making the compositors more
> considerate about their Xwayland configuration. I believe the global
> trend is to move towards the compositor having all the configurability
> in itself, and all the other components having a single source of
> configuration in the running system: the compositor. I would compare
> Xwayland to libinput here.

Yes, but that means that all compositors need to have this "configurability", 
even though it's actually Xwayland that uses it.

> I realize recognizing glamor issues is a pain at the moment as you
> don't have a setting to disable glamor. However, the environment
> variable you suggest needs to be already set when the compositor
> starts. You suggest an /etc/profile.d/ script, which requires root to
> set up. I might ask if adding that env var to avoid writing a script,
> replacing the Xwayland binary, to exec the original Xwayland binary
> with an additional command line argument is that much of an improvement?

That's what I use myself, when I am debugging an issue, but but it's no so 
practical to tell users top write a wrapper script, rename the binary from 
their distro package and replace it with their own script... That's precisely 
why I am looking in other solutions.

As glamor also depends on the drivers and thus the hardware, there are issues 
(including rendering issues) that I can never reproduce myself.
 
> Xwayland is not a program launched manually, but Xephyr is, isn't it?
> That makes an env var very convenient with Xephyr, less so with
> Xwayland.

I have seen glamor issues with Xwayland that do not show up in Xephyr, we 
cannot always use Xephyr to investigate glamor issues (or the underlying 
layers), https://bugs.freedesktop.org/show_bug.cgi?id=99400 is one of them...

> Are there already other env vars useful with Xwayland (debugging)?

Not that I am aware, except GLAMOR_DEBUG.
 
> Are there other features in Xwayland one might want to configure too?

Not really, I was starting to write a man page for Xwayland and realized few 
options are actualy to any use for the reguilar user, as Xwayland is mostly 
useful when started by the compositor.

> Should Xwayland get its own configuration file a la xorg.conf, or
> should we go with just arguments passed from parent process (the
> compositor)?

I thought of that, but deemed it a overkill :)
 
> Here's another thought:
> 
> If the compositor detects that Xwayland crashed, maybe it could
> automatically disable glamor when restarting Xwayland? Or show a dialog
> saying what happened and let the user choose whether to try with or
> without glamor the next time to help diagnose the issue?

That's an ideal workld unfortunately, mutter requires Xwayland t orun and won;t 
survive a crash in Xwayland (unlike weston), so if Xwayland dies s does the 
entire gnome-shell Wayland session.

Besides, that won't help much with rendering issues with glamor.

> I suppose that's not an option for gnome-shell as gnome-shell crashes
> with Xwayland, does it not? Maybe in the future it could though?

Exactly.
 
> This is just food for thought, I don't want to NAK this patch just by
> my own opinion.

Yeap, I appreciate your views and share most of them, I am not a big fan of 
environment variables for such purpose either (that's why I sent this patch as 
an RFC), but I've felt many times that frustration of not being able to tell 
simply to a user to try Xwayland without glamor...

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Pekka Paalanen]

On Wed,  1 Mar 2017 17:45:11 +0100
Olivier Fourdan  wrote:

> Hi all,
> 
> I am seeing quite a few Xwayland crashes related to glamor.
> 
> Various issues, could be with glamor itself or with the drivers (like the
> issues I witness with nv30), whatever.
> 
> To investigate those issues (or even unblock affected users) it's often
> useful to disable glamor -even temporarily- but Xwayland doesn't use an
> xorg.conf and relies solely on the command line.
> 
> Not all compositors allow for customizing the command line, gnome-shell
> or mutter for example have the command line and path to the Xwayland binary
> hardcoded, which makes it harder for users to disable glamor acceleration
> in Xwayland by adding -shm to the command line (glamor being used by
> default).
> 
> Would adding an environment variable such as XWAYLAND_NO_GLAMOR (similar
> to what Xephyr does with e.g. XEPHYR_NO_SHM) make sense here? 
> 
> I tried and it works with the following patch added, by setting the
> environment variable XWAYLAND_NO_GLAMOR in a /etc/profile.d/ script on
> Fedora 25.

Hi,

I understand the attractiveness of adding an override, bypassing the
compositors like this. But, essentially it is just that: a
configuration bypass.

I would prefer leaning towards just making the compositors more
considerate about their Xwayland configuration. I believe the global
trend is to move towards the compositor having all the configurability
in itself, and all the other components having a single source of
configuration in the running system: the compositor. I would compare
Xwayland to libinput here.

I realize recognizing glamor issues is a pain at the moment as you
don't have a setting to disable glamor. However, the environment
variable you suggest needs to be already set when the compositor
starts. You suggest an /etc/profile.d/ script, which requires root to
set up. I might ask if adding that env var to avoid writing a script,
replacing the Xwayland binary, to exec the original Xwayland binary
with an additional command line argument is that much of an improvement?

Xwayland is not a program launched manually, but Xephyr is, isn't it?
That makes an env var very convenient with Xephyr, less so with
Xwayland.

Are there already other env vars useful with Xwayland (debugging)?

Are there other features in Xwayland one might want to configure too?
Should Xwayland get its own configuration file a la xorg.conf, or
should we go with just arguments passed from parent process (the
compositor)?

Here's another thought:

If the compositor detects that Xwayland crashed, maybe it could
automatically disable glamor when restarting Xwayland? Or show a dialog
saying what happened and let the user choose whether to try with or
without glamor the next time to help diagnose the issue?

I suppose that's not an option for gnome-shell as gnome-shell crashes
with Xwayland, does it not? Maybe in the future it could though?


This is just food for thought, I don't want to NAK this patch just by
my own opinion.


Thanks,
pq


pgpAjirrSypTj.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH xserver v2] xwayland: add envvar XWAYLAND_NO_GLAMOR

[Olivier Fourdan]

Not all compositors allow for customizing the Xwayland command line,
gnome-shell/mutter for example have the command line and path to
Xwayland binary hardcoded, which makes it harder for users to disable
glamor acceleration in Xwayland (glamor being used by default).

Add an environment variable XWAYLAND_NO_GLAMOR to disable glamor support
in Xwayland.

Signed-off-by: Olivier Fourdan 
Reviewed-by: Eric Engestrom 
---
 v2: Fix typo in commit message, add r-b Eric Engestrom

 hw/xwayland/xwayland-glamor.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c
index 65c3c00..ee30f81 100644
--- a/hw/xwayland/xwayland-glamor.c
+++ b/hw/xwayland/xwayland-glamor.c
@@ -552,6 +552,13 @@ Bool
 xwl_glamor_init(struct xwl_screen *xwl_screen)
 {
 ScreenPtr screen = xwl_screen->screen;
+const char *no_glamor_env;
+
+no_glamor_env = getenv("XWAYLAND_NO_GLAMOR");
+if (no_glamor_env && *no_glamor_env != '0') {
+ErrorF("Disabling glamor and dri3 support, XWAYLAND_NO_GLAMOR is 
set\n");
+return FALSE;
+}
 
 if (xwl_screen->egl_context == EGL_NO_CONTEXT) {
 ErrorF("Disabling glamor and dri3, EGL setup failed\n");
-- 
2.9.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH xserver] xwayland: add envvar XWAYLAND_NO_GLAMOR

[Olivier Fourdan]

Hi Eric,

> > Not all compositors allow for customizing the Xwayland command line,
> > gnome-shell/mutter for example have the command line and path to
> > Xwayland binary hardcoded, which makes it harder for users to disable
> > glamor acceleration in Xwayland (glamor being used by default).
> > 
> > Add an environment variable XWAYLAND_NO_GLAMOR t odiable glamor support
> 
> "to disable"

I can't type... v2 with an updated commit message is on its way.
 
> The change itself looks good to me.
> Reviewed-by: Eric Engestrom 

Thanks!
 
> As to whether it's a good idea to allow this, I'd say it is, but you
> might want the opinion of someone who's more involved in this project :)

Cheers,
Olivier
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 19/68] compositor-drm: Refcount drm_fb

[Pekka Paalanen]

On Wed, 1 Mar 2017 11:17:14 +
Daniel Stone  wrote:

> Hi,
> 
> On 1 March 2017 at 10:29, Pekka Paalanen  wrote:
> > On Tue, 28 Feb 2017 14:46:21 + Daniel Stone  
> > wrote:  
> >> On 28 February 2017 at 10:59, Pekka Paalanen  wrote:  
> >> > The important thing to document about this change is that is exchanges
> >> > a (almost never hit) double-unref into a (always hit) leak of the
> >> > drm_fb. It would be even better to mention what patch shall fix the
> >> > introduced leak.  
> >>
> >> I ... don't think it does leak? At least not if it gets successfully 
> >> displayed.  
> >
> > Hmm, yes, on a second look after sleeping several nights, I see calls
> > to drm_fb_get_from_bo() are pretty much balanced with drm_fb_unref.
> >
> > But because this patch adds refcounting, and adds only calls to
> > drm_fb_ref() without adding corresponding calls to unref, then I think
> > the code just before this patch was somehow broken, because this patch
> > as is definitely changes behaviour.  
> 
> Sure, I can move the drm_fb_ref() addition into a follow-up patch if
> you'd prefer. Let me know.

Hi,

the thing I care highly about is that the commit message explains
all the consequences of a patch. Or at least all the consequences the
author and reviewers can think of, particularly the subtle ones.

Which patch adds the drm_fb_ref() is secondary to that in my opinion.

I believe that is important for the atomic series in particular,
because the series is very long, and we'd prefer landing it piece by
piece once reviews agree. That means upstream master will remain at
intermediate steps for some time.

Some more words in the commit message should be fine, I think, to show
that the detail has been acknowledged. A counter example is the stray
timer_arm() in the global output repaint patch. :-)

In general, anything to explain odd things to avoid reviewers getting
confused would be nice, IMHO. ;-)

> >> Every drm_fb_get_from_bo() whilst the BO is live, sure. But these are
> >> balanced by drm_fb_unref (formerly drm_output_release_fb) calls in,
> >> say, vblank_handler. So I can't really see a leak, and even if there
> >> were, planes are disabled by default. Maybe scanout, but that's
> >> trivially broken right now anyway, so not the biggest of regressions
> >> as far as I'm concerned, if it even is one - and I can't quite see it.  
> >
> > Scanout is broken? Since when?
> >
> > I used it successfully when reproducing
> > https://bugs.freedesktop.org/show_bug.cgi?id=98833 or is that exactly
> > the breakage you refer to?  
> 
> ISTR the problem was that, if you repeatedly hit the repaint loop (due
> to damage, even if everything was occluded), the buffer currently on
> scanout could get released too early? It's hard to remember though; so
> many bugs, and this series has been going such a long time.

Which release do you mean?

If we were to destroy the drm_fb too early, wouldn't that lead to CRTC
being turned off, which would essentially kill the output completely,
since we don't know to mode-set again? Or can page flip turn it on?

If we were to send wl_buffer.release too early, then the client might
drawn into it too early... which actually sounds like it might be
relevant to fdo#98833.

Anyway, that's not too important here.


Thanks,
pq


pgplTKATacqct.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston v3] ivi-shell: add_screen_remove_layer API

[Ucan, Emre (ADITG/SW1)]

It is analagous to layer_remove_surface API.
The API removes a layer from the render order
of the screen.

v3:
add the new vfunc at the end of
the ivi_layout_interface struct.

Signed-off-by: Emre Ucan 
---
 ivi-shell/ivi-layout-export.h |   10 ++
 ivi-shell/ivi-layout.c|   22 ++
 2 files changed, 32 insertions(+)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 2317d6e..39ffde1 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -578,6 +578,16 @@ struct ivi_layout_interface {
 */
struct ivi_layout_surface *
(*get_surface)(struct weston_surface *surface);
+
+   /**
+* \brief Remove a ivi_layer to a weston_output which is currently 
managed
+* by the service
+*
+* \return IVI_SUCCEEDED if the method call was successful
+* \return IVI_FAILED if the method call was failed
+*/
+   int32_t (*screen_remove_layer)(struct weston_output *output,
+  struct ivi_layout_layer *removelayer);
 };
 
 #ifdef __cplusplus
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 64e4ead..5edf88b 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1663,6 +1663,27 @@ ivi_layout_screen_add_layer(struct weston_output *output,
 }
 
 static int32_t
+ivi_layout_screen_remove_layer(struct weston_output *output,
+   struct ivi_layout_layer *removelayer)
+{
+   struct ivi_layout_screen *iviscrn;
+
+   if (output == NULL || removelayer == NULL) {
+   weston_log("ivi_layout_screen_remove_layer: invalid 
argument\n");
+   return IVI_FAILED;
+   }
+
+   iviscrn = get_screen_from_output(output);
+
+   wl_list_remove(>pending.link);
+   wl_list_init(>pending.link);
+
+   iviscrn->order.dirty = 1;
+
+   return IVI_SUCCEEDED;
+}
+
+static int32_t
 ivi_layout_screen_set_render_order(struct weston_output *output,
   struct ivi_layout_layer **pLayer,
   const int32_t number)
@@ -2087,6 +2108,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
 */
.get_screens_under_layer= ivi_layout_get_screens_under_layer,
.screen_add_layer   = ivi_layout_screen_add_layer,
+   .screen_remove_layer= ivi_layout_screen_remove_layer,
.screen_set_render_order= ivi_layout_screen_set_render_order,
 
/**
-- 
1.7.9.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel