Re: [PATCH libinput 1/5] tools: if the execdir is the builddir, add it to the path

2018-07-04 Thread Peter Hutterer 
On Wed, Jul 04, 2018 at 11:29:26AM +0100, Emil Velikov wrote:
> Hi Peter,
> 
> On 28 June 2018 at 00:51, Peter Hutterer  wrote:
> > When running libinput tools from the builddir, look up the subtools in the
> > builddir as well. Otherwise, add the install prefix to the list of lookup
> > locations.
> >
> > This ensures that a) we're running builddir stuff against builddir stuff, 
> > but
> > also b) that we're not running builddir stuff against installed stuff 
> > because
> > that may give us false positives.
> >
> > Signed-off-by: Peter Hutterer 
> > ---
> > Similar-ish to the git approach Emil suggested in [1] but git is a lot more
> > involved here. Since we only need this for debugging tools, we can pick the
> > simpler approach here and simply ignore most of the corner cases.
> >
> I think that git does thing in that particular way is to ensure a
> consistent lookup approach.

yeah, git cares a lot more about different platforms and features and it
works around a relocatable (relative) execdir. And comparing to the prefix
is 'safer' because you're not leaking the builddir into the binary. But for
this particular use-case ... meh :)

> Personally tools_execdir_is_builddir reads like it should return a
> bool, sadly no better name comes to mind.

indeed. I'll see if I come up with something more telling but given the
limited impact I'm happy enough with the current name. Thanks for the
review.

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

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread Alan Griffiths 
Reviewed-by: Alan Griffiths 


On 18/06/18 11:16, Simon Ser wrote:
> This adds a new protocol to negotiate server-side rendering of window
> decorations for xdg-toplevels. This allows compositors that want to draw
> decorations themselves to send their preference to clients, and clients that
> prefer server-side decorations to request them.
>
> This is inspired by a protocol from KDE [1] which has been implemented in
> KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> provides an updated protocol with those concerns taken into account.
>
> Signed-off-by: Simon Ser 
>
> [1] 
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> [2] 
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> ---
>
> (Sorry, I somehow managed to send the old version and not the v7 one in my
> previous email)
>
> This was iterated on privately between representatives of Sway and wlroots
> (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
> Mir (Alan Griffiths).
>
> A proof-of-concept of a client and server implementation is available at [1].
>
> Changes from v6 to v7:
> - Move errors in xdg_toplevel_decoration
> - Add errors descriptions
> - Add an error when toplevel is destroyed before decoration
> - State that objects created with the manager are still valid after
>   destroying the manager
> - Compositors can no longer ignore set_mode requests, but they can
>   disregard the client's preference
> - Describe how clients whose preference depend on the window state
>   should behave to prevent frames with unwanted state
>
> [1] https://github.com/swaywm/wlroots/pull/1053
>
>  Makefile.am   |   1 +
>  unstable/xdg-decoration/README|   4 +
>  .../xdg-decoration-unstable-v1.xml| 156 ++
>  3 files changed, 161 insertions(+)
>  create mode 100644 unstable/xdg-decoration/README
>  create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..71909d8 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -17,6 +17,7 @@ unstable_protocols =
> \
>   
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
>  \
>   unstable/xdg-output/xdg-output-unstable-v1.xml  
> \
>   unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README
> new file mode 100644
> index 000..73f0c52
> --- /dev/null
> +++ b/unstable/xdg-decoration/README
> @@ -0,0 +1,4 @@
> +xdg_decoration protocol
> +
> +Maintainers:
> +Simon Ser 
> diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml 
> b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> new file mode 100644
> index 000..378e8ff
> --- /dev/null
> +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> @@ -0,0 +1,156 @@
> +
> +
> +  
> +Copyright © 2018 Simon Ser
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  This interface allows a compositor to announce support for server-side
> +  decorations.
> +
> +  A window decoration is a set of window controls as deemed appropriate 
> by
> +  the party managing them, such as user interface components used to 
> move,
> +  resize and change a window's state.
> +
> +  A client can use this protocol to request being decorated by a 
> supporting
> +  compositor.
> +
> +  If compositor and client do not negotiate the use of a

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread Simon Ser 
On July 4, 2018 3:45 PM, Jonas Ådahl  wrote:
> Looks good to me, I think we can go with this. What Reviewed-by:s should
> I add, besides my own?

I think everybody has replied with a tag as of now.

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

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread Eike Hein 


On 07/04/2018 11:45 PM, Jonas Ådahl wrote:
> Looks good to me, I think we can go with this. What Reviewed-by:s should
> I add, besides my own?


Reviewed-by: Eike Hein 


> Jonas

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

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread David Edmundson 
Reviewed-by: David Edmundson 
​
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread Drew DeVault 
Reviewed-by: Drew DeVault 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread Jonas Ådahl 
On Wed, Jul 04, 2018 at 09:01:43AM -0400, Simon Ser wrote:
> Hi Jonas,
> 
> Any news about this?

Looks good to me, I think we can go with this. What Reviewed-by:s should
I add, besides my own?


Jonas

> 
> Thanks,
> 
> Simon
> 
> On June 27, 2018 5:23 PM, Simon Ser  wrote:
> > Hi Jonas,
> >
> > What do you think of this new version? Wording suggestions and other 
> > comments
> > welcome :)
> >
> > Thanks,
> >
> > Simon
> >
> > On June 18, 2018 11:16 AM, Simon Ser  wrote:
> > > This adds a new protocol to negotiate server-side rendering of window
> > > decorations for xdg-toplevels. This allows compositors that want to draw
> > > decorations themselves to send their preference to clients, and clients 
> > > that
> > > prefer server-side decorations to request them.
> > >
> > > This is inspired by a protocol from KDE [1] which has been implemented in
> > > KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> > > provides an updated protocol with those concerns taken into account.
> > >
> > > Signed-off-by: Simon Ser 
> > >
> > > [1] 
> > > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > > [2] 
> > > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> > > ---
> > >
> > > (Sorry, I somehow managed to send the old version and not the v7 one in my
> > > previous email)
> > >
> > > This was iterated on privately between representatives of Sway and wlroots
> > > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), 
> > > and
> > > Mir (Alan Griffiths).
> > >
> > > A proof-of-concept of a client and server implementation is available at 
> > > [1].
> > >
> > > Changes from v6 to v7:
> > > - Move errors in xdg_toplevel_decoration
> > > - Add errors descriptions
> > > - Add an error when toplevel is destroyed before decoration
> > > - State that objects created with the manager are still valid after
> > >   destroying the manager
> > > - Compositors can no longer ignore set_mode requests, but they can
> > >   disregard the client's preference
> > > - Describe how clients whose preference depend on the window state
> > >   should behave to prevent frames with unwanted state
> > >
> > > [1] https://github.com/swaywm/wlroots/pull/1053
> > >
> > >  Makefile.am   |   1 +
> > >  unstable/xdg-decoration/README|   4 +
> > >  .../xdg-decoration-unstable-v1.xml| 156 ++
> > >  3 files changed, 161 insertions(+)
> > >  create mode 100644 unstable/xdg-decoration/README
> > >  create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> > >
> > > diff --git a/Makefile.am b/Makefile.am
> > > index 4b9a901..71909d8 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -17,6 +17,7 @@ unstable_protocols =
> > > \
> > >   
> > > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> > >  \
> > >   unstable/xdg-output/xdg-output-unstable-v1.xml  
> > > \
> > >   unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > > + unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> > >   $(NULL)
> > >
> > >  stable_protocols =   
> > > \
> > > diff --git a/unstable/xdg-decoration/README 
> > > b/unstable/xdg-decoration/README
> > > new file mode 100644
> > > index 000..73f0c52
> > > --- /dev/null
> > > +++ b/unstable/xdg-decoration/README
> > > @@ -0,0 +1,4 @@
> > > +xdg_decoration protocol
> > > +
> > > +Maintainers:
> > > +Simon Ser 
> > > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml 
> > > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> > > new file mode 100644
> > > index 000..378e8ff
> > > --- /dev/null
> > > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> > > @@ -0,0 +1,156 @@
> > > +
> > > +
> > > +  
> > > +Copyright © 2018 Simon Ser
> > > +
> > > +Permission is hereby granted, free of charge, to any person 
> > > obtaining a
> > > +copy of this software and associated documentation files (the 
> > > "Software"),
> > > +to deal in the Software without restriction, including without 
> > > limitation
> > > +the rights to use, copy, modify, merge, publish, distribute, 
> > > sublicense,
> > > +and/or sell copies of the Software, and to permit persons to whom the
> > > +Software is furnished to do so, subject to the following conditions:
> > > +
> > > +The above copyright notice and this permission notice (including the 
> > > next
> > > +paragraph) shall be included in all copies or substantial portions 
> > > of the
> > > +Software.
> > > +
> > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > EXPRESS OR
> > > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > MERCHANTABILITY,
> > > +FITNESS

Re: EXT: [PATCH weston 2/2] libweston: fix output reflow on removal

2018-07-04 Thread Ray, Ian (GE Healthcare) 


> On 21 Jun 2018, at 15.53, Pekka Paalanen  wrote:
> 
> From: Pekka Paalanen 
> 
> This is regression apparently introduced in
> 0de859ede4bad72b5d3b78e086632f02196d997f, which accidentally swapped the
> sign of 'delta_width' in the original call site. If one removes an
> output, the remaining outputs on the right are getting moved even
> further to the right.
> 
> The outputs to the right should be moved to the left instead, to close
> the gap left by the removed output.
> 

Reviewed-by: Ian Ray 


> Reported-by: Tomasz Olszak 
> Signed-off-by: Pekka Paalanen 
> ---
> libweston/compositor.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libweston/compositor.c b/libweston/compositor.c
> index 8e01eacc..516be96b 100644
> --- a/libweston/compositor.c
> +++ b/libweston/compositor.c
> @@ -5409,7 +5409,7 @@ weston_compositor_remove_output(struct weston_output 
> *output)
> 
>   weston_presentation_feedback_discard_list(>feedback_list);
> 
> - weston_compositor_reflow_outputs(compositor, output, output->width);
> + weston_compositor_reflow_outputs(compositor, output, -output->width);
> 
>   wl_list_remove(>link);
>   wl_list_insert(compositor->pending_output_list.prev, >link);
> -- 
> 2.16.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

Re: [PATCH wayland-protocols v7] unstable: add xdg-decoration protocol

2018-07-04 Thread Simon Ser 
Hi Jonas,

Any news about this?

Thanks,

Simon

On June 27, 2018 5:23 PM, Simon Ser  wrote:
> Hi Jonas,
>
> What do you think of this new version? Wording suggestions and other comments
> welcome :)
>
> Thanks,
>
> Simon
>
> On June 18, 2018 11:16 AM, Simon Ser  wrote:
> > This adds a new protocol to negotiate server-side rendering of window
> > decorations for xdg-toplevels. This allows compositors that want to draw
> > decorations themselves to send their preference to clients, and clients that
> > prefer server-side decorations to request them.
> >
> > This is inspired by a protocol from KDE [1] which has been implemented in
> > KDE and Sway and was submitted for consideration in 2017 [2]. This patch
> > provides an updated protocol with those concerns taken into account.
> >
> > Signed-off-by: Simon Ser 
> >
> > [1] 
> > https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > [2] 
> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> > ---
> >
> > (Sorry, I somehow managed to send the old version and not the v7 one in my
> > previous email)
> >
> > This was iterated on privately between representatives of Sway and wlroots
> > (Simon Ser, Drew DeVault and Tony Crisci), KDE and Qt (David Edmundson), and
> > Mir (Alan Griffiths).
> >
> > A proof-of-concept of a client and server implementation is available at 
> > [1].
> >
> > Changes from v6 to v7:
> > - Move errors in xdg_toplevel_decoration
> > - Add errors descriptions
> > - Add an error when toplevel is destroyed before decoration
> > - State that objects created with the manager are still valid after
> >   destroying the manager
> > - Compositors can no longer ignore set_mode requests, but they can
> >   disregard the client's preference
> > - Describe how clients whose preference depend on the window state
> >   should behave to prevent frames with unwanted state
> >
> > [1] https://github.com/swaywm/wlroots/pull/1053
> >
> >  Makefile.am   |   1 +
> >  unstable/xdg-decoration/README|   4 +
> >  .../xdg-decoration-unstable-v1.xml| 156 ++
> >  3 files changed, 161 insertions(+)
> >  create mode 100644 unstable/xdg-decoration/README
> >  create mode 100644 unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 4b9a901..71909d8 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -17,6 +17,7 @@ unstable_protocols =  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> > +   unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> > $(NULL)
> >
> >  stable_protocols = 
> > \
> > diff --git a/unstable/xdg-decoration/README b/unstable/xdg-decoration/README
> > new file mode 100644
> > index 000..73f0c52
> > --- /dev/null
> > +++ b/unstable/xdg-decoration/README
> > @@ -0,0 +1,4 @@
> > +xdg_decoration protocol
> > +
> > +Maintainers:
> > +Simon Ser 
> > diff --git a/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml 
> > b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> > new file mode 100644
> > index 000..378e8ff
> > --- /dev/null
> > +++ b/unstable/xdg-decoration/xdg-decoration-unstable-v1.xml
> > @@ -0,0 +1,156 @@
> > +
> > +
> > +  
> > +Copyright © 2018 Simon Ser
> > +
> > +Permission is hereby granted, free of charge, to any person obtaining a
> > +copy of this software and associated documentation files (the 
> > "Software"),
> > +to deal in the Software without restriction, including without 
> > limitation
> > +the rights to use, copy, modify, merge, publish, distribute, 
> > sublicense,
> > +and/or sell copies of the Software, and to permit persons to whom the
> > +Software is furnished to do so, subject to the following conditions:
> > +
> > +The above copyright notice and this permission notice (including the 
> > next
> > +paragraph) shall be included in all copies or substantial portions of 
> > the
> > +Software.
> > +
> > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > EXPRESS OR
> > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > MERCHANTABILITY,
> > +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > SHALL
> > +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> > OTHER
> > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> > +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> > +DEALINGS IN THE SOFTWARE.
> > +  
> > +
> > +  
> > +
> > +  This interface allows a compositor to announce

Re: [PATCH libinput 1/5] tools: if the execdir is the builddir, add it to the path

2018-07-04 Thread Emil Velikov 
Hi Peter,

On 28 June 2018 at 00:51, Peter Hutterer  wrote:
> When running libinput tools from the builddir, look up the subtools in the
> builddir as well. Otherwise, add the install prefix to the list of lookup
> locations.
>
> This ensures that a) we're running builddir stuff against builddir stuff, but
> also b) that we're not running builddir stuff against installed stuff because
> that may give us false positives.
>
> Signed-off-by: Peter Hutterer 
> ---
> Similar-ish to the git approach Emil suggested in [1] but git is a lot more
> involved here. Since we only need this for debugging tools, we can pick the
> simpler approach here and simply ignore most of the corner cases.
>
I think that git does thing in that particular way is to ensure a
consistent lookup approach.
Personally tools_execdir_is_builddir reads like it should return a
bool, sadly no better name comes to mind.

More of an jfyi, than anything else.

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

Re: [PATCH wayland 4/8] fixup! scanner: use c99 initializers for the request/events arrays

2018-07-04 Thread Pekka Paalanen 
On Tue, 3 Jul 2018 16:19:03 +0100
Emil Velikov  wrote:

> On 3 July 2018 at 12:28, Pekka Paalanen  wrote:
> > On Thu, 14 Jun 2018 16:49:41 +0100
> > Emil Velikov  wrote:
> >  
> >> ---
> >>  tests/data/example-code.c   | 238 
> >> 
> >>  tests/data/small-code-core.c|   8 +-
> >>  tests/data/small-code.c |   8 +-
> >>  tests/data/small-private-code.c |   8 +-
> >>  4 files changed, 131 insertions(+), 131 deletions(-)  
> >  
> >> diff --git a/tests/data/small-private-code.c 
> >> b/tests/data/small-private-code.c
> >> index 35fa653..84f77de 100644
> >> --- a/tests/data/small-private-code.c
> >> +++ b/tests/data/small-private-code.c
> >> @@ -54,13 +54,13 @@ static const struct wl_interface *types[] = {
> >>  };
> >>
> >>  static const struct wl_message intf_A_requests[] = {
> >> - { "rq1", "sun", types + 0 },
> >> - { "rq2", "nsiufho", types + 1 },
> >> - { "destroy", "", types + 0 },
> >> + { .name = "rq1", .signature = "sun", .types = [0] },
> >> + { .name = "rq2", .signature = "nsiufho", .types = [1] },
> >> + { .name = "destroy", .signature = "", .types = [0] },
> >>  };  
> >
> > Hi,
> >
> > this change doesn't look more readable to me than the old version.
> > Adding the field names only clutters things and makes the lines longer
> > for no added information: it is always the exact same fields set in the
> > same order, and there are only three of them.
> >
> > The change from 'types + i' to '[i]' seems ok though.
> >  
> Seems like these dead trivial patches are inciting some bike-shedding.
> Proceed as you wish, sadly I'm out of patience.

Ok, let's drop these all these, continue with other matters.


Thanks,
pq


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

Re: Same ilm surface on multiple layer support

2018-07-04 Thread Ikshwaku Chauhan 
Hello Wataru ,

Could you please suggest on this blocking behavior of LayerManagerControl
with multi screen/layer?
We have applied this patch:  e8ff7df863a10eb4be5273017fb544b5f823fc6a  as
you suggested, but issue is not resolved.

Best Regards,
Ikshwaku

On Fri, May 11, 2018 at 11:21 AM, Vikas Patil  wrote:

> Hi Wataru,
>
> I have tried it and unfortunately it do not solve the issue. Is it known
> issue or it is happening due to older (1.11.0) version of weston and ivi
> which i am using.
>
> Best Regards,
> Vikash
>
> On Thu, May 10, 2018 at 3:54 PM, Mizuno, Wataru (ADITJ/SWG) <
> wmiz...@jp.adit-jv.com> wrote:
>
>> Hi Vikas,
>>
>>
>>
>> This issue might be fixed with this patch: e8ff7df863a10eb4be5273017fb544
>> b5f823fc6a
>>
>>
>>
>> Please try with it.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> *Wataru Mizuno*
>>
>> ADITJ / SWG
>>
>>
>>
>> +81-(0)566-56-0946
>>
>>
>>
>> *From:* Vikas Patil [mailto:vikasmpa...@gmail.com ]
>>
>> *Sent:* Thursday, May 10, 2018 4:07 PM
>> *To:* Ucan, Emre (ADITG/ESB)
>> *Cc:* genivi-ivi-layer-managem...@lists.genivi.org; Mizuno, Wataru
>> (ADITJ/SWG); wayland mailing list; Ikshwaku Chauhan
>> *Subject:* Re: Same ilm surface on multiple layer support
>>
>>
>>
>> Hi All,
>>
>> As some of the LayerManagerControl commands do not work when same surface
>> is attached to two layers.
>>
>> Following command hangs and do not come out as expected. I tried to check
>> where it is hanging using GDB. Is this gives some hit on issue and
>> resolution? Please suggest if you have any pointers.
>>
>> LayerManagerControl get scene
>>
>>
>> root@linux1:~# gdb -p 916
>> warning: Unable to find libthread_db matching inferior's thread library,
>> thread debugging will not be available.
>> warning: Unable to find libthread_db matching inferior's thread library,
>> thread debugging will not be available.
>>
>> 0x4ddf68f4 in wl_list_length () from /usr/lib/libwayland-client.so.0
>> (gdb) bt
>> #0  0x4ddf68f4 in wl_list_length () from /usr/lib/libwayland-client.so.0
>> #1  0x4deb45e4 in ilm_getSurfaceIDsOnLayer ()
>>from /usr/lib/libilmControl.so.1.11.0
>> #2  0x00033f80 in printLayerProperties(unsigned int, char const*) ()
>> #3  0x00035a40 in printScene() ()
>> #4  0x0001d4e8 in func_2(Expression*) ()
>> #5  0x000330ac in ExpressionInterpreter::interpr
>> etCommand(std::__cxx11::basic_string,
>> std::allocator >) ()
>> #6  0x00018d50 in main ()
>>
>> Regards,
>>
>> Vikash
>>
>>
>>
>> On Tue, Apr 17, 2018 at 10:51 AM, Vikas Patil 
>> wrote:
>>
>> Hi Emre,
>>
>> Could you please suggest on this blocking behavior of LayerManagerControl
>> with multi screen/layer?
>>
>> Thank You.
>>
>> Best Regards,
>>
>> Vikash
>>
>>
>>
>> On Wed, Apr 11, 2018 at 11:35 AM, Vikas Patil 
>> wrote:
>>
>> Hi Emre Ucan,
>>
>> Thanks a lot for your quick response. I am able to show same surface on
>> two layers now. I have taken following two commit to weston 1.11.0.
>> Attached here same as  patch to weston 1.11.0.
>>
>> "5e8d55da698e58"
>> "67bd21232fa549"
>>
>> However if I use any of the below commands to analyze then it is not
>> exiting and I need to prress "CTRl+C" to come out from command. Do you know
>> if this is the normal behavior or some fix is available for this ?
>>
>> root@linux-a1 :~# LayerManagerControl analyze surface 10
>> ^C
>>
>> root@ linux-a1 :~# LayerManagerControl get scene
>> screen 0 (0x0)
>> ---
>> - resolution:   x=800, y=480
>> - hardware layer count: 0
>> - layer render order:   1000(0x3e8), 2000(0x7d0),
>>
>> layer 1000 (0x3e8)
>> ---
>> - created by pid:   0
>> - original size:x=400, y=480
>> - destination region:   x=0, y=0, w=400, h=480
>> - source region:x=0, y=0, w=400, h=480
>> - orientation:  0 (up is top)
>> - opacity:  1
>> - visibility:   1
>> - type: 0 (unknown)
>> ^C
>>
>>
>> root@linux-a1:~# LayerManagerControl get layer 1000
>> layer 1000 (0x3e8)
>> ---
>> - created by pid:   0
>> - original size:x=400, y=480
>> - destination region:   x=0, y=0, w=400, h=480
>> - source region:x=0, y=0, w=400, h=480
>> - orientation:  0 (up is top)
>> - opacity:  1
>> - visibility:   1
>> - type: 0 (unknown)
>> ^C
>>
>> root@orinoco-9939-a1:~# LayerManagerControl get surface 10
>> surface 10 (0xa)
>> ---
>> - created by pid:   821
>> - original size:  x=800, y=480
>> - destination region: x=0, y=0, w=400, h=480
>> - source region:  x=0, y=0, w=800, h=480
>> - orientation:0 (up is top)
>> - opacity:1
>> - visibility: 1
>> - pixel format:   0 (R-8)
>> - native surface: 0
>> - counters:   frame=0, draw=0, update=0
>> ^C
>>
>> Also following commands worked successfully.
>>
>>
>> LayerManagerControl get screen 0
>>

Re: LayerManagerControl dump surface command is not working with gstreamer pipeline.

2018-07-04 Thread Ikshwaku Chauhan 
Dear All,

Could anyone help us in resolving this issue?

Additional info: we are using waylandsink with ivi-shell.

Thanks in advance.

Best Regards,
Ikshwaku

On Wed, Jun 20, 2018 at 6:58 PM, Ikshwaku Chauhan  wrote:

> Dear All,
>
>
>
> We are facing issue when we are trying to take the surface dump for a
> video running on the display. we are observing the following behaviors:
>
>
>
> 1. When we run a video file through gstreamer
>  pipeline then, not able to take the
> surface dump with LayerManagerControl command.
>
> Command used : LayerManagerControl dump surface 90 to surface.png  Only
> getting a dot when we zoom in the generated image file.
>
>
>
> 2. But able to get the screen dump for video playback
>
> Command used: LayerManagerControl dump screen 0 to screen.png. Getting the
> proper screen dump.
>
>
>
> 3. When we run EGLWLMockNavigation, then both surface and screen dumps are
> working properly.
>
>
>
> We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
> on TI's Soc.
>
> Could anyone tell us what might be the issue, or we are missing any
> configuration?
>
>
>
> Thanks in advance.
>
>
>
> Best Regards,
>
> Ikshwaku
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel