Re: Same ilm surface on multiple layer support

[Vikas Patil]

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 <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::interpretCommand(std::__cxx11::basic_string<char,
> std::char_traits, std::allocator >) ()
> #6  0x00018d50 in main ()
>
> Regards,
>
> Vikash
>
>
>
> On Tue, Apr 17, 2018 at 10:51 AM, Vikas Patil <vikasmpa...@gmail.com>
> 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 <vikasmpa...@gmail.com>
> 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:   fra

Re: Same ilm surface on multiple layer support

[Vikas Patil]

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::interpretCommand(std::__cxx11::basic_string<char,
std::char_traits, std::allocator >) ()
#6  0x00018d50 in main ()

Regards,
Vikash

On Tue, Apr 17, 2018 at 10:51 AM, Vikas Patil <vikasmpa...@gmail.com> 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 <vikasmpa...@gmail.com>
> 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
>> LayerManagerControl get layer 2000
>> LayerManagerControl get layers
>> LayerManagerControl get surfaces
>>
>> I used following commands to setup  and test
>>
>> export XDG_RUNTIME_DIR=/var/run/root/1000
>>
>> LayerManagerControl create layer 1000 400 480
>> LayerManagerControl set layer 1000 visibility 1
>> LayerManagerControl set layer 1000 destination region 0 0 400 480
>>
>> LayerManagerControl create layer 2000 400 480
>> LayerManagerControl set layer 2000 visibility 1
>> LayerManagerControl set layer 2000 destination region 400 0 400 480
>>
>> LayerManagerControl set screen 0 render order 1000,2000
>>
>> EGLWLMockNavigation &
>> LayerManagerCont

Re: Same ilm surface on multiple layer support

[Vikas Patil]

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 <vikasmpa...@gmail.com> 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
> LayerManagerControl get layer 2000
> LayerManagerControl get layers
> LayerManagerControl get surfaces
>
> I used following commands to setup  and test
>
> export XDG_RUNTIME_DIR=/var/run/root/1000
>
> LayerManagerControl create layer 1000 400 480
> LayerManagerControl set layer 1000 visibility 1
> LayerManagerControl set layer 1000 destination region 0 0 400 480
>
> LayerManagerControl create layer 2000 400 480
> LayerManagerControl set layer 2000 visibility 1
> LayerManagerControl set layer 2000 destination region 400 0 400 480
>
> LayerManagerControl set screen 0 render order 1000,2000
>
> EGLWLMockNavigation &
> LayerManagerControl add surface 10 to layer 1000
> LayerManagerControl add surface 10 to layer 2000
> LayerManagerControl set surface 10 visibility 1
> LayerManagerControl set surface 10 source region 0 0 800 480
> LayerManagerControl set surface 10 destination region 0 0 400 480
>
> Best Regards,
> Vikash
>
> On Tue, Apr 10, 2018 at 7:43 PM, Ucan, Emre (ADITG/ESB) <
> eu...@de.adit-jv.com> wrote:
>
>> Hi Vikas,
>>
>>
>>
>> This patch “5e8d55da698e58”  enabled the feature. It is part of weston
>> 1.12 release.
>>
>>
>>
>> Best regards
>>
>> *Emre Ucan*
>> Engineering Software Base (ADITG/ESB)
>>
>> Tel. +49 5121 49 6937
>>
>> *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
>> *On Behalf Of *Vikas Patil
>> *Sent:* Dienstag, 10. April 2018 14:58
>> *To:* genivi-ivi-layer-managem...@lists.genivi.org; Mizuno, Wataru
>> (ADITJ/SWG); wayland mailing list
>> *Subject:* Same ilm surface on multiple layer support
>>
>>
>>
>> +Subject
>>
>> Dear All,
>>
>> We are facing issue when we are trying to add same surface to multiple
>> layers. When we try to attach surface to another layer, it is getting
>> detached from the earlier layer.
>>
>> We are using wayland/weston/wayland-ivi-extension 1.11.0 with
>> drm-backend on TI's Soc.
>>
>> Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
>> in newer version and can it be ported

Re: Same ilm surface on multiple layer support

[Vikas Patil]

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
LayerManagerControl get layer 2000
LayerManagerControl get layers
LayerManagerControl get surfaces

I used following commands to setup  and test

export XDG_RUNTIME_DIR=/var/run/root/1000

LayerManagerControl create layer 1000 400 480
LayerManagerControl set layer 1000 visibility 1
LayerManagerControl set layer 1000 destination region 0 0 400 480

LayerManagerControl create layer 2000 400 480
LayerManagerControl set layer 2000 visibility 1
LayerManagerControl set layer 2000 destination region 400 0 400 480

LayerManagerControl set screen 0 render order 1000,2000

EGLWLMockNavigation &
LayerManagerControl add surface 10 to layer 1000
LayerManagerControl add surface 10 to layer 2000
LayerManagerControl set surface 10 visibility 1
LayerManagerControl set surface 10 source region 0 0 800 480
LayerManagerControl set surface 10 destination region 0 0 400 480

Best Regards,
Vikash

On Tue, Apr 10, 2018 at 7:43 PM, Ucan, Emre (ADITG/ESB) <
eu...@de.adit-jv.com> wrote:

> Hi Vikas,
>
>
>
> This patch “5e8d55da698e58”  enabled the feature. It is part of weston
> 1.12 release.
>
>
>
> Best regards
>
> *Emre Ucan*
> Engineering Software Base (ADITG/ESB)
>
> Tel. +49 5121 49 6937
>
> *From:* wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org]
> *On Behalf Of *Vikas Patil
> *Sent:* Dienstag, 10. April 2018 14:58
> *To:* genivi-ivi-layer-managem...@lists.genivi.org; Mizuno, Wataru
> (ADITJ/SWG); wayland mailing list
> *Subject:* Same ilm surface on multiple layer support
>
>
>
> +Subject
>
> Dear All,
>
> We are facing issue when we are trying to add same surface to multiple
> layers. When we try to attach surface to another layer, it is getting
> detached from the earlier layer.
>
> We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
> on TI's Soc.
>
> Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
> in newer version and can it be ported to 1.11.0 ? or Is there any other way
> to show same surface on multiple layers?
>
> I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].
>
>
>
> *"Currently 1 layer can be only on 1 screen, and 1 surface can be only on 1 
> layer, we are planning to relax this limitation And allow 1 surface to be on 
> many layers but we would need to break the ABI and change the  ivi-controller 
> protocol."*
>
> [1] https://lists.genivi.org/pipermail/genivi-ivi-layer-
> management/2016-October/005416.html
>
>
>
> Thanking you in advance.
>
>
>
> Best Regards,
>
> Vikash
>


0001-ivi-shell-introduce-ivi_layout_view.patch
Description: Binary data


0001-ivi-shell-remove-ivi_layout_get_weston_view.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Same ilm surface on multiple layer support

[Vikas Patil]

 +Subject

Dear All,

We are facing issue when we are trying to add same surface to multiple
layers. When we try to attach surface to another layer, it is getting
detached from the earlier layer.

We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
on TI's Soc.

Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
in newer version and can it be ported to 1.11.0 ? or Is there any other way
to show same surface on multiple layers?

I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].

*"Currently 1 layer can be only on 1 screen, and 1 surface can be only *
*on 1 layer, we are planning to relax this limitation And allow 1 **surface *
*to be on many layers but we would need to break the ABI and change
the  **ivi-controller protocol."*

[1] https://lists.genivi.org/pipermail/genivi-ivi-layer-
management/2016-October/005416.html

Thanking you in advance.

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

ikshwaku.ec2...@gmail.com

[Vikas Patil]

Dear All,

We are facing issue when we are trying to add same surface to multiple
layers. When we try to attach surface to another layer, it is getting
detached from the earlier layer.

We are using wayland/weston/wayland-ivi-extension 1.11.0 with drm-backend
on TI's Soc.

Could anyone know if this is the limitation of ILM 1.11.0 ? Is this fixed
in newer version and can it be ported to 1.11.0 ? or Is there any other way
to show same surface on multiple layers?

I see it was the limitation with wayland-ivi-extesnion 1.9.0 as below [1].

*"Currently 1 layer can be only on 1 screen, and 1 surface can be only *
*on 1 layer, we are planning to relax this limitation And allow 1 **surface *
*to be on many layers but we would need to break the ABI and change
the  **ivi-controller protocol."*

[1]
https://lists.genivi.org/pipermail/genivi-ivi-layer-management/2016-October/005416.html

Thanking you in advance.

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

Re: [wayland + ILM] proxy wrappers usage of wayland 1.11.0 to 1.9.0

[Vikas Patil]

Thanks a lot Philipp for your comments, it really helped. Now I get
the display correctly. However now I get the segmentation at different
location with my uses case [1] after back porting patches from wayland
1.11.0 to 1.9.0 and and also utilizing proxy wrappers in ILM control
library.

(gdb) bt
#0  0x68d11554 in wl_array_copy (array=0x67d2eb98, source=0x1) at
/usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-util.c:145
#1  0x in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


[1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/

Thanks & Regards,
Vikash

On Fri, Aug 18, 2017 at 7:35 PM, Philipp Kerling <pkerl...@casix.org> wrote:
> Hi,
>
> Am Freitag, den 18.08.2017, 18:35 +0530 schrieb Vikas Patil:
>> Dear All,
>>
>>
>> I have backported following patches from wayland 1.11.0 to 1.9.0 to
>> test one crash issue [1] . I am able to backport and start Weston
>> with
>> it. Is this valid thing to do?
>>
>>
>> https://cgit.freedesktop.org/wayland/wayland/commit/?id=6d29c0da3cd16
>> 8e08187cd204d2314188479c0f1
>> [client: Introduce proxy wrappers]
>>
>> https://cgit.freedesktop.org/wayland/wayland/commit/?id=6fe12f02e3b48
>> 79cd3d5faa08f023cc761d13be9
>> [client: Fix wl_display_roundtrip_queue() race condition]
>>
>> https://cgit.freedesktop.org/wayland/wayland/commit/?id=69ec70fb0d3f7
>> 5f4bcce449238d6297f6a986b5f
>> [tests/queue-test: Add tests for proxy wrappers] -- not required.
>>
>>
>>
>> Now If I understand it correctly I need to use/modify code where the
>> wayland client creates the proxy and sets the queue. One such
>> components is [2] ILM control library. I tried to do as per the
>> patches but with it nothing is coming on display even though weston
>> starts successfully with ivi-shell and ivi-controller.so.
>>
>>
>> Attached here the modified file. I would like to understand if the
>> way I used is correct or not? Could someone explain this fix and How
>> to use it properly for ILM control library? Do I need to add similar
>> fix in qtwayland  5.5.1 and other such components (e.g. wayland sink
>> from gstreamer) ?
> I think there are some problems judging by a quick look at your file:
>  * You create a wrapper for the wl_display, but then call
>wl_display_get_registry on your original display. You need to use
>the wrapped display here.
>  * Consequently, you must set the queue on the wl_display wrapper
>before that so it correctly gets inherited to the wl_registry.
>  * I don't understand what you use wl_display_sync for. You do know
>that wl_display_roundtrip_queue uses that implicitly?
>  * You must add the registry listener immediately after creating it and
>not dispatch any events (on the queue the registry uses) in between.
>Otherwise they will get lost.
>
> You might want to take a look at how other libraries use the API, e.g.
> https://github.com/01org/libva/blob/master/va/wayland/va_wayland_drm.c#L251
>
> If other libraries you use also operate on global objects in a thread-
> unsafe way (i.e. they are not using proxy wrappers *and* you cannot
> guarantee that the main queue will not be dispatched in parallel) then
> you will have to patch them.
>
> Regards
> Philipp
>
>
>>
>> [1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/
>> 034784.html
>>
>> [2] https://github.com/GENIVI/wayland-ivi-extension/blob/1.9.1/ivi-la
>> yermanagement-api/ilmControl/src/ilm_control_wayland_platform.c
>> (function: init_control(),  line: 1260 )
>>
>>
>> Thanking you in advance for your time and comments.
>>
>>
>>
>> Thanks & Regards,
>>
>> Vikash
>> ___
>> 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

[wayland + ILM] proxy wrappers usage of wayland 1.11.0 to 1.9.0

[Vikas Patil]

Dear All,


I have backported following patches from wayland 1.11.0 to 1.9.0 to
test one crash issue [1] . I am able to backport and start Weston with
it. Is this valid thing to do?


https://cgit.freedesktop.org/wayland/wayland/commit/?id=6d29c0da3cd168e08187cd204d2314188479c0f1
[client: Introduce proxy wrappers]

https://cgit.freedesktop.org/wayland/wayland/commit/?id=6fe12f02e3b4879cd3d5faa08f023cc761d13be9
[client: Fix wl_display_roundtrip_queue() race condition]

https://cgit.freedesktop.org/wayland/wayland/commit/?id=69ec70fb0d3f75f4bcce449238d6297f6a986b5f
[tests/queue-test: Add tests for proxy wrappers] -- not required.



Now If I understand it correctly I need to use/modify code where the
wayland client creates the proxy and sets the queue. One such
components is [2] ILM control library. I tried to do as per the
patches but with it nothing is coming on display even though weston
starts successfully with ivi-shell and ivi-controller.so.


Attached here the modified file. I would like to understand if the
way I used is correct or not? Could someone explain this fix and How
to use it properly for ILM control library? Do I need to add similar
fix in qtwayland  5.5.1 and other such components (e.g. wayland sink
from gstreamer) ?


[1] https://lists.freedesktop.org/archives/wayland-devel/2017-August/034784.html

[2] 
https://github.com/GENIVI/wayland-ivi-extension/blob/1.9.1/ivi-layermanagement-api/ilmControl/src/ilm_control_wayland_platform.c
(function: init_control(),  line: 1260 )


Thanking you in advance for your time and comments.



Thanks & Regards,

Vikash
/**
 *
 * Copyright (C) 2013 DENSO CORPORATION
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 *
 /
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 

#include 

#include "ilm_common.h"
#include "ilm_control_platform.h"
#include "wayland-util.h"
#include "ivi-controller-client-protocol.h"
#include "ivi-input-client-protocol.h"

/* GCC visibility */
#if defined(__GNUC__) && __GNUC__ >= 4
#define ILM_EXPORT __attribute__ ((visibility("default")))
#else
#define ILM_EXPORT
#endif

struct layer_context {
struct wl_list link;

struct ivi_controller_layer *controller;
t_ilm_uint id_layer;

struct ilmLayerProperties prop;
layerNotificationFunc notification;

struct {
struct wl_list list_surface;
struct wl_list link;
} order;

struct wayland_context *ctx;
};

struct screen_context {
struct wl_list link;

struct wl_output *output;
struct ivi_controller_screen *controller;
t_ilm_uint id_from_server;
t_ilm_uint id_screen;
int32_t transform;

struct ilmScreenProperties prop;

struct {
struct wl_list list_layer;
} order;

struct ilm_control_context *ctx;
};

static inline void lock_context(struct ilm_control_context *ctx)
{
   pthread_mutex_lock(>mutex);
}

static inline void unlock_context(struct ilm_control_context *ctx)
{
   pthread_mutex_unlock(>mutex);
}

static int init_control(void);

static struct surface_context* get_surface_context(struct wayland_context *, uint32_t);

void release_instance(void);

static int create_controller_layer(struct wayland_context *ctx, t_ilm_uint width, t_ilm_uint height, t_ilm_layer layerid);

static int32_t
wayland_controller_is_inside_layer_list(struct wl_list *list,
uint32_t id_layer)
{
struct layer_context *ctx_layer = NULL;
wl_list_for_each(ctx_layer, list, link) {
if (ctx_layer->id_layer == id_layer) {
return 1;
}
}

return 0;
}

static struct layer_context*
wayland_controller_get_layer_context(struct wayland_context *ctx,
 uint32_t id_layer)
{
struct layer_context *ctx_layer = NULL;

if (ctx->controller == NULL) {
fprintf(stderr, "controller is not initialized in ilmControl\n");
return NULL;
}

wl_list_for_each(ctx_layer, >list_layer, link) {
if (ctx_layer->id_layer == id_layer) {
return ctx_layer;
}
}

return NULL;
}

static void
output_listener_geometry(void *data,
 struct wl_output *output,
 int32_t x,
 int32_t y,
 int32_t physical_width,

[wayland+ILM] Understanding crash in wayland lib with media playback

[Vikas Patil]

Dear All,

I am observing crash with following callstack. Is this known issue to
anyone here and fixed with latest version? How should one debug such
issues? Any inputs, comments or suggestion to debug and fix this issue
would be very helpful.

I am suspecting it is related to bug
https://bugs.freedesktop.org/show_bug.cgi?id=91273  but how to confirm
it?

I am planing to test with wayland/weston/wayland-ivi-extension 1.11.0.

Use-case: This is with video playback and clicking on next menu for
next video multiple times.

We are using i.MX6 based target on linux 4.1 and following packages
with fbdev-backend and ivi-shell with ivi-controller.so.

In one configuration ILM (client and control apis are used directly)
in gui application while with other configuration there is central
controller (layer manager) for managinf view of gui. However with both
the configuration this is observed.

wayland 1.9.0
weston 1.9.0
waylandivi-extension 1.9.1
qtwayland 5.5.1
media playback framework: cinemo or gstreamer (with both the framework
we observed the crash) with wayland/ILM support.

Callsatck:

(gdb) bt
#0  0x68f4a384 in wl_list_insert (list=0x68eace68, elm=0x617c3c48,
elm@entry=0x68f472d0 ) at
/usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-util.c:51
#1  0x68f47310 in queue_event (len=24, display=0xc) at
/usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:1127
#2  read_events (display=0xc) at
/usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:1212
#3  0x68f47e40 in wl_display_read_events (display=0x614fd178) at
/usr/src/debug/wayland/1.9.0-r0/wayland-1.9.0/src/wayland-client.c:1324
#4  0x4ba52a5c in control_thread (p_ret=) at
/usr/src/debug/wayland-ivi-extension/1.9.1-r0/git/ivi-layermanagement-api/ilmControl/src/ilm_control_wayland_platform.c:1234
#5  0x4af9607c in start_thread (arg=0x677df3b0) at pthread_create.c:339
#6  0x4af20a20 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.s from
/data/work/vmp/workspace/sdk/sysroots/cortexa9hf-vfp-neon-elina-linux-gnueabi/lib/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thanking you for your time in advance.

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Linux: Smooth splashscreen with system having weston with drm-backend

[Vikas Patil]

On Thu, Jul 13, 2017 at 7:20 PM, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> On Thu, Jul 13, 2017 at 3:33 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
>> Dear All,
>>
>> I am looking for an solution to have early smooth splashscreen on the
>> Linux system with Weston and drm-backend.
>>
>> I tried showing splashscreen using Linux logo and fbcon Linux features
>> but it is not smooth as when system boots logo gets displayed via
>> kernel and as the Weston starts
>> I see flicker and blackscreen.
>>
>> Another approach I tried is having standalone drm api based
>> application [1] which uses the one of the available hardware
>> plane/overlay for displaying splash image and Weston is
>> starting and uses default plane which is different from plane utilized
>> by above application. but still I see flicker and black screen when
>> Weston starts.
>>
>> I want splash to be displayed on one of the h/w plane and Weston
>> should start in background without any flicker and black screen on
>> some other plane.
>>
>> Anyone here before achieved such a use case with such system? Looking
>> for inputs/suggestions/ideas to achieve this. It is ok if something
>> needs to be hacked/changd at any level (kernel driver, weston).
>>
>> This is required on platform such as TI (Jacinto) and Intel (Broxton)
>> or devices based on drm graphics stack.
>>
>> [1] 
>> http://git.ti.com/glsdk/example-applications/blobs/39080525baca7bf136f2412d62436366a736af6b/drm-tests/drm_z_alpha.c
>>
>> Thanking you all for your time and inputs in advance.
>
> If you make sure you have matching modes between the 2 users of drm
> this should work. kms drivers (especially if they are already
> converted to atomic) will automatically optimize transitions to not
> flicker (if possible).
>

I am not sure how this will work. As per what I understood is when
drmModeSetCrtc() is called it uses the primary/default plane and if
application wants to use any other plane then it need to setup the
planes using drmModeSetPlane() in application before doing
drmModeSetCrtc() so when primary plane scan-outs at crtc phase it also
knows it has to compose from using other planes too. This is what
splash application is doing. But when I run weston after splash app,
weston  I think calls drmModeSetCrtc() without the knowledge of planes
and previous configuration overrides so it doesn't work.

> If you still flicker then it's either a kernel driver issue, a hw
> limitations (some hw needs a full modeset for e.g. changing the bit
> depth) or you program two different things.
>
> Also, you must ensure that the boot-splash does not quit until weston
> has fully taken over, otherwise kms will first shut down the screen
> (when the splash quits), then re-enable it when weston starts.
>
I have tried adding while with sleep in splash app but still the
behavior is same. FYI, I am doing this on TI's Jacinto6 platform but
similar required on intel platform too.

I was also thinking if there is something  can be done in drm-backend
of weston. e.g disabling mode setting or some code but not sure if
weston will work with it..

Thanks & regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to configure/use/assign hardware pipeline/plane for specific application?

[Vikas Patil]

Thanks Pekka for explaining it. May be I will have a look once Daniel
shares the latest branch details.

On Fri, Jun 9, 2017 at 5:10 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 9 Jun 2017 15:02:03 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> On Fri, Jun 9, 2017 at 1:16 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>> >
>> > On Fri, 9 Jun 2017 12:31:22 +0530
>> > Vikas Patil <vikasmpa...@gmail.com> wrote:
>> >
>> > > Dear All,
>> > >
>> > > I am using wayland/weston 1.11.0 (with ivi-shell and drm-backend) with
>> > > DRA7xx (TI's automotive SoC) and Linux  4.4. I am investigating on how
>> > > could wayalnd based application can be assigned to use particular 
>> > > pipeline.
>> > >
>> > > Use-case details:
>> > > As TI's DRA7xx SoC provides 1 graphics and 3 video pipeline (also 
>> > > refereed
>> > > as plane).  For example I would like to assign GFX pipeline to GUI
>> > > application, VID1 pipeline to video player, VID2
>> > > pipeline to camera application and VID3 for some other application.
>> > >
>> > > I can see currently weston uses only GFX pipeline.  Is there a way to do
>> > > this using wayland/weston? What needs to be done to achieve this?
>> >
>> > Hi,
>> >
>> > the proper solution is to get the atomic modesetting patch series by
>> > Daniel Stone reviewed, finalized, and merged. This is the foundation
>> > for how weston could use additional DRM planes at all.
>> >
>> > Once that is done, the window manager needs to ensure that the
>> > scenegraph is always compatible with putting the surfaces you want on
>> > the DRM planes you want. With ivi-shell that is very possible as you
>> > have unique identification for every application surface. Then, there
>> > might be tweaks needed in the libweston DRM-backend to achieve the
>> > correct automatic surface/plane associations.
>> >
>> > The major point here is that one does not explicitly configure a
>> > surface for a DRM plane in Weston or via protocol. The DRM planes will
>> > be used automatically for any surfaces that might fit.
>>
>> Thanks a lot for your quick comments.
>>
>> What are the fitting criteria for mapping surfaces to plane
>> automatically? What happens if number of surfaces are more than
>> available planes, which surface gets the plane (in case some specific
>> application desire to use plane not the other apps)? We have a use
>> case where we want multiple applications to use the particular plane
>> only?
>>
>> How the other h/w features for planes (z-order, global alpha, rotation
>> ) are handled with this? Is there any way to utilize this also?
>
> Hi,
>
> the scenegraph is essentially a stack of views (surfaces). A simple
> algorithm is to start from the top and check view by view:
>
> - is the buffer compatible with any available DRM planes
> - does the view fit on a plane
> - given what is laid above this view in the scenegraph, is it even
>   possible to promote the view onto a plane or would it violate
>   z-ordering, transparency/blending, etc.
> - ...
>
> The difficult part is to find the optimal view/plane assignment, and
> the above greedy algorithm is not guaranteed to find that optimal
> solution.
>
> z-order, alpha, rotation, all that comes from the scenegraph and is
> taken into account when assigning planes. After all, the visual result
> must be according to Weston's scenegraph. Using scenegraph features
> that cannot be realized with DRM planes is a sure way to prevent the
> view from ever going on a plane.
>
> Any views that were not assigned to overlay planes will be flattened by
> the renderer onto the primary DRM plane.
>
> That would be the starting point. A more sophisticated example would be
> Android's HWC2 (hardware composer).
>
>> > Weston's  architecture currently in master (let alone in something as old 
>> > as
>> > 1.11) does not support interactions between the shell
>> > plugin and the backend plugin to explicitly and permanently configure
>> > the DRM plane assignments. It's not inconceivable to add the necessary
>> > infrastructure, but I would see if the implicit approach works first.
>> >
>>
>> > If you want to give the patch series a go, I believe Daniel can point
>> > you to the latest branches.
>> >
>> I could give a try but not sure if the kernel from TI BSP (4.4.23)
>> supports at

Re: How to configure/use/assign hardware pipeline/plane for specific application?

[Vikas Patil]

On Fri, Jun 9, 2017 at 1:16 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>
> On Fri, 9 Jun 2017 12:31:22 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
> > Dear All,
> >
> > I am using wayland/weston 1.11.0 (with ivi-shell and drm-backend) with
> > DRA7xx (TI's automotive SoC) and Linux  4.4. I am investigating on how
> > could wayalnd based application can be assigned to use particular pipeline.
> >
> > Use-case details:
> > As TI's DRA7xx SoC provides 1 graphics and 3 video pipeline (also refereed
> > as plane).  For example I would like to assign GFX pipeline to GUI
> > application, VID1 pipeline to video player, VID2
> > pipeline to camera application and VID3 for some other application.
> >
> > I can see currently weston uses only GFX pipeline.  Is there a way to do
> > this using wayland/weston? What needs to be done to achieve this?
>
> Hi,
>
> the proper solution is to get the atomic modesetting patch series by
> Daniel Stone reviewed, finalized, and merged. This is the foundation
> for how weston could use additional DRM planes at all.
>
> Once that is done, the window manager needs to ensure that the
> scenegraph is always compatible with putting the surfaces you want on
> the DRM planes you want. With ivi-shell that is very possible as you
> have unique identification for every application surface. Then, there
> might be tweaks needed in the libweston DRM-backend to achieve the
> correct automatic surface/plane associations.
>
> The major point here is that one does not explicitly configure a
> surface for a DRM plane in Weston or via protocol. The DRM planes will
> be used automatically for any surfaces that might fit.

Thanks a lot for your quick comments.

What are the fitting criteria for mapping surfaces to plane
automatically? What happens if number of surfaces are more than
available planes, which surface gets the plane (in case some specific
application desire to use plane not the other apps)? We have a use
case where we want multiple applications to use the particular plane
only?

How the other h/w features for planes (z-order, global alpha, rotation
) are handled with this? Is there any way to utilize this also?

> Weston's  architecture currently in master (let alone in something as old as
> 1.11) does not support interactions between the shell
> plugin and the backend plugin to explicitly and permanently configure
> the DRM plane assignments. It's not inconceivable to add the necessary
> infrastructure, but I would see if the implicit approach works first.
>

> If you want to give the patch series a go, I believe Daniel can point
> you to the latest branches.
>
I could give a try but not sure if the kernel from TI BSP (4.4.23)
supports atomic mode setting (generic and TI SoC specific if any). How
to to check if atomic mode setting is supported or not in kernel? Do I
also need to update the wayland/weston to latest version or I can
apply the patches to 1.11.0? I also need to know how to test then if
able to apply the patches and run the weston? Which version of
Wayland-ivi-extension I need to use with these patches or first need
to tested with desktop-shell?

I found the patches at https://phabricator.freedesktop.org/T7595 but
it would be helpful to get the branch details. I see this patches are
tested again intel and rockchip hw. Are they generic and supposed to
work on other SoCs (DRA7XX TI) or some feature required to be
supported in kernel/bsp to utilize this?

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

How to configure/use/assign hardware pipeline/plane for specific application?

[Vikas Patil]

Dear All,

I am using wayland/weston 1.11.0 (with ivi-shell and drm-backend) with
DRA7xx (TI's automotive SoC) and Linux  4.4. I am investigating on how
could wayalnd based application can be assigned to use particular pipeline.

Use-case details:
As TI's DRA7xx SoC provides 1 graphics and 3 video pipeline (also refereed
as plane).  For example I would like to assign GFX pipeline to GUI
application, VID1 pipeline to video player, VID2
pipeline to camera application and VID3 for some other application.

I can see currently weston uses only GFX pipeline.  Is there a way to do
this using wayland/weston? What needs to be done to achieve this?



Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [Video] ILM support for waylandsink query

[Vikas Patil]

Hi Eugen,

Yes, I have implemented using protocol and it is working. However I also
want to try it with direct usage of ILM apis but no luck yet. I have done
the same with glimagesink, eglvivsink video sink plugin and it is working.

Thanks & Regards,
Vikash

On Tue, Mar 28, 2017 at 1:09 AM, Eugen Friedrich <fried...@gmail.com> wrote:

> Hi Vikash,
>
> i could not really find this out from the call stack but the problem
> could be that the ilmClient api is not thread safe, and in upstream
> direct after 1.11 release we decided to deprecated this,
> so just remove the ilmClient calls and use wayland protocol directly
> and you can continue to use the ilmCommon api this one is thread save.
>
> Hope this helps,
> Eugen
>
> 2017-03-27 10:35 GMT+02:00 Vikas Patil <vikasmpa...@gmail.com>:
> > Hi All,
> >
> > Modifying the view port as follows solves the issue 1. However still not
> > getting what could be the cause of segmentation fault with direct usage
> of
> > ILM apis.
> >
> >   //wl_viewport_set_destination (window->video_viewport, res.w, res.h);
> >   wl_viewport_set_destination (window->video_viewport, 800, 480);
> >
> > Thanks & Regards,
> > Vikash
> >
> > On Fri, Mar 24, 2017 at 3:28 PM, Vikas Patil <vikasmpa...@gmail.com>
> wrote:
> >>
> >> Dear All,
> >>
> >> I am trying to add support for wayland-ivi-extension 1.11.0 to
> waylandsink
> >> [1] (video sink plug-in from gstreamer1.0-plugins-bad package) for
> Jacinto6
> >> SoC using following two methods.
> >>
> >> 1. Using ivi-application protocol similar to simple-egl.c (test from
> >> weston)
> >> - This works.
> >> - Here is video size is 1280x720 and screen resolution is 800x480 then
> >> only top left of video is visible. How should I fix this?
> >>
> >>
> >> 2. Using ilmClient and ilmControl APIs directly.
> >> - This do not work and gives segmentation fault with below call stack. I
> >> have checked the calls and setup seems correct to me.
> >> - I thought it might be wayland sink uses drm protocol to allocate
> buffers
> >> which will be attached to  created surfaces and tried to disable
> thatpath
> >> and instead use SHM.
> >> With this also the same behavior.
> >>
> >> Any inputs? Attached here the patch for wayland sink which implements
> ilm
> >> support.
> >>
> >> Any inputs after looking at the call stack?
> >>
> >> #0  0xb6812928 in wl_proxy_marshal_constructor (proxy=0x150410,
> >> opcode=opcode@entry=1, interface=0xb6827714 )
> >> at ../wayland-1.11.0/src/wayland-client.c:729
> >> #1  0xb6851e98 in wl_display_get_registry (wl_display=)
> at
> >> /usr/include/wayland-client-protocol.h:957
> >> #2  init_client () at
> >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-
> layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:207
> >> #3  get_client_instance () at
> >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-
> layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:235
> >> #4  0xb6852128 in wayland_surfaceCreate (nativehandle=3051387744,
> >> width=, height=, pixelFormat= out>,
> >> pSurfaceId=0xb688fe04 )
> >> at
> >> /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-
> layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:273
> >> #5  0xb687cb10 in create_ilm_surface (window=0xb5e05150,
> display=0x150410)
> >> at ../../../git/ext/wayland/wlwindow.c:252
> >> #6  gst_wl_window_new_internal (display=0x150410) at
> >> ../../../git/ext/wayland/wlwindow.c:383
> >> #7  0xb687d3b4 in gst_wl_window_new_toplevel (display=,
> >> info=info@entry=0x14fff0) at ../../../git/ext/wayland/wlwindow.c:395
> >> #8  0xb68787c0 in gst_wayland_sink_render (bsink=0x14fde8,
> >> buffer=0xb5504b68) at ../../../git/ext/wayland/gstwaylandsink.c:658
> >> #9  0xb691b134 in gst_base_sink_do_preroll () from
> >> /usr/lib/libgstbase-1.0.so.0
> >> Cannot access memory at address 0x0
> >> #10 0x0014fde8 in ?? ()
> >> Cannot access memory at address 0x0
> >> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> >>
> >>
> >> [1]
> >> https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/
> tree/ext/wayland?id=1.6.3
> >>
> >> Thanks you all in advance.
> >>
> >> Thanks & Regards,
> >> Vikash
> >
> >
> >
> > ___
> > 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: [Video] ILM support for waylandsink query

[Vikas Patil]

Hi All,

Modifying the view port as follows solves the issue 1. However still not
getting what could be the cause of segmentation fault with direct usage of
ILM apis.

  //wl_viewport_set_destination (window->video_viewport, res.w, res.h);
  wl_viewport_set_destination (window->video_viewport, 800, 480);

Thanks & Regards,
Vikash

On Fri, Mar 24, 2017 at 3:28 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:

> Dear All,
>
> I am trying to add support for wayland-ivi-extension 1.11.0 to waylandsink
> [1] (video sink plug-in from gstreamer1.0-plugins-bad package) for Jacinto6
> SoC using following two methods.
>
> 1. Using ivi-application protocol similar to simple-egl.c (test from
> weston)
> - This works.
> - Here is video size is 1280x720 and screen resolution is 800x480 then
> only top left of video is visible. How should I fix this?
>
>
> 2. Using ilmClient and ilmControl APIs directly.
> - This do not work and gives segmentation fault with below call stack. I
> have checked the calls and setup seems correct to me.
> - I thought it might be wayland sink uses drm protocol to allocate buffers
> which will be attached to  created surfaces and tried to disable thatpath
> and instead use SHM.
> With this also the same behavior.
>
> Any inputs? Attached here the patch for wayland sink which implements ilm
> support.
>
> Any inputs after looking at the call stack?
>
> #0  0xb6812928 in wl_proxy_marshal_constructor (proxy=0x150410,
> opcode=opcode@entry=1, interface=0xb6827714 )
> at ../wayland-1.11.0/src/wayland-client.c:729
> #1  0xb6851e98 in wl_display_get_registry (wl_display=) at
> /usr/include/wayland-client-protocol.h:957
> #2  init_client () at /usr/src/debug/wayland-ivi-
> extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/
> src/ilm_client_wayland_platform.c:207
> #3  get_client_instance () at /usr/src/debug/wayland-ivi-
> extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/
> src/ilm_client_wayland_platform.c:235
> #4  0xb6852128 in wayland_surfaceCreate (nativehandle=3051387744,
> width=, height=, pixelFormat=,
> pSurfaceId=0xb688fe04 )
> at /usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-
> layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:273
> #5  0xb687cb10 in create_ilm_surface (window=0xb5e05150, display=0x150410)
> at ../../../git/ext/wayland/wlwindow.c:252
> #6  gst_wl_window_new_internal (display=0x150410) at
> ../../../git/ext/wayland/wlwindow.c:383
> #7  0xb687d3b4 in gst_wl_window_new_toplevel (display=,
> info=info@entry=0x14fff0) at ../../../git/ext/wayland/wlwindow.c:395
> #8  0xb68787c0 in gst_wayland_sink_render (bsink=0x14fde8,
> buffer=0xb5504b68) at ../../../git/ext/wayland/gstwaylandsink.c:658
> #9  0xb691b134 in gst_base_sink_do_preroll () from
> /usr/lib/libgstbase-1.0.so.0
> Cannot access memory at address 0x0
> #10 0x0014fde8 in ?? ()
> Cannot access memory at address 0x0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
>
> [1] https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/
> tree/ext/wayland?id=1.6.3
>
> Thanks you all in advance.
>
> Thanks & Regards,
> Vikash
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[Video] ILM support for waylandsink query

[Vikas Patil]

Dear All,

I am trying to add support for wayland-ivi-extension 1.11.0 to waylandsink
[1] (video sink plug-in from gstreamer1.0-plugins-bad package) for Jacinto6
SoC using following two methods.

1. Using ivi-application protocol similar to simple-egl.c (test from weston)
- This works.
- Here is video size is 1280x720 and screen resolution is 800x480 then only
top left of video is visible. How should I fix this?


2. Using ilmClient and ilmControl APIs directly.
- This do not work and gives segmentation fault with below call stack. I
have checked the calls and setup seems correct to me.
- I thought it might be wayland sink uses drm protocol to allocate buffers
which will be attached to  created surfaces and tried to disable thatpath
and instead use SHM.
With this also the same behavior.

Any inputs? Attached here the patch for wayland sink which implements ilm
support.

Any inputs after looking at the call stack?

#0  0xb6812928 in wl_proxy_marshal_constructor (proxy=0x150410,
opcode=opcode@entry=1, interface=0xb6827714 )
at ../wayland-1.11.0/src/wayland-client.c:729
#1  0xb6851e98 in wl_display_get_registry (wl_display=) at
/usr/include/wayland-client-protocol.h:957
#2  init_client () at
/usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:207
#3  get_client_instance () at
/usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:235
#4  0xb6852128 in wayland_surfaceCreate (nativehandle=3051387744,
width=, height=, pixelFormat=,
pSurfaceId=0xb688fe04 )
at
/usr/src/debug/wayland-ivi-extension/1.11.0-r1/git/ivi-layermanagement-api/ilmClient/src/ilm_client_wayland_platform.c:273
#5  0xb687cb10 in create_ilm_surface (window=0xb5e05150, display=0x150410)
at ../../../git/ext/wayland/wlwindow.c:252
#6  gst_wl_window_new_internal (display=0x150410) at
../../../git/ext/wayland/wlwindow.c:383
#7  0xb687d3b4 in gst_wl_window_new_toplevel (display=,
info=info@entry=0x14fff0) at ../../../git/ext/wayland/wlwindow.c:395
#8  0xb68787c0 in gst_wayland_sink_render (bsink=0x14fde8,
buffer=0xb5504b68) at ../../../git/ext/wayland/gstwaylandsink.c:658
#9  0xb691b134 in gst_base_sink_do_preroll () from
/usr/lib/libgstbase-1.0.so.0
Cannot access memory at address 0x0
#10 0x0014fde8 in ?? ()
Cannot access memory at address 0x0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)


[1]
https://cgit.freedesktop.org/gstreamer/gst-plugins-bad/tree/ext/wayland?id=1.6.3

Thanks you all in advance.

Thanks & Regards,
Vikash


ilm_support_1_6_3_waylandsink_1.patch
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Dual display in clone mode with weston and wayland-ivi-extension

[Vikas Patil]

Hi Emre Ucan,

>>This feature is supported in IVI-Shell but not in ilmControl libraries.
What does exactly this means? Does this mean I could not do this via
LayerManagerControl and could not use ilm APIs directly to do this? I need
to use the ivi-shell protocol.

>>Today I will send a big update to wayland-ivi-extension to support this
feature.
Is this already pushed?

Thanking you.

Regards,
Vikash

On Fri, Mar 10, 2017 at 3:01 PM, Ucan, Emre (ADITG/SW1) <
eu...@de.adit-jv.com> wrote:

> Hi Vikash,
>
> You can basically add the same surface on different layers and attach
> these layers to different screens.
>
> This feature is supported in IVI-Shell but not in ilmControl libraries.
> The libraries assumes that a surface could be only on one layer.
>
> Today I will send a big update to wayland-ivi-extension to support this
> feature.
>
> Best regards
>
> Emre Ucan
> Software Group I (ADITG/SW1)
>
> Tel. +49 5121 49 6937
>
> > -Original Message-
> > From: wayland-devel [mailto:wayland-devel-
> > boun...@lists.freedesktop.org] On Behalf Of Vikas Patil
> > Sent: Freitag, 10. März 2017 07:45
> > To: wayland mailing list; genivi-ivi-layer-managem...@lists.genivi.org;
> Pekka
> > Paalanen
> > Subject: Dual display in clone mode with weston and wayland-ivi-extension
> >
> > Dear All,
> >
> > Do wayland/weston or wayland-ivi-extension supports dual display in clone
> > mode? If not,  is there any way I can configure weston or wayland-ivi-
> > extension to operate dual display in clone mode?
> >
> > Is there any plan to support this? Any suggestions/inputs on How can I
> > achieve this?
> >
> > Thanks & Regards,
> > Vikash
> >
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Dual display in clone mode with weston and wayland-ivi-extension

[Vikas Patil]

Dear All,

Do wayland/weston or wayland-ivi-extension supports dual display in clone
mode? If not,  is there any way I can configure weston or
wayland-ivi-extension to operate dual display in clone mode?

Is there any plan to support this? Any suggestions/inputs on How can I
achieve this?

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland/weston 1.9.0 and glimagesingk gstreamer wayland sink query with i.MX6

[Vikas Patil]

Hi Pekka,

Thanks for comments. I forgot to update this thread. With I.mx6 platform
when I do not set XDG_RUNTIME_DIR, glimagesink uses framebuffer interface
and do not use Wayland and this is why it works.

Thanks a lot for your comments.

Thanks & Regards,
Vikash

On Mar 6, 2017 2:18 PM, "Pekka Paalanen" <ppaala...@gmail.com> wrote:

On Wed, 8 Feb 2017 19:28:10 +0530
Vikas Patil <vikasmpa...@gmail.com> wrote:

> Dear All,
>
>
>
> When I run simple video application (which pause and play gstreamer
> pipeline continuously) based on following pipeline [1] with  weston
1.9.0  and
> glimagesink (part of gstreamer1.0-plugins-bad 1.6.0 package) on i.MX6
based
> platform and Linux 4.1 without exporting (export
> XDG_RUNTIME_DIR=/var/run/root/1000) then it works fine and runs as long as
> I want.

You should not be able to run weston at all without XDG_RUNTIME_DIR
properly set up.

> However when I export (export XDG_RUNTIME_DIR=/var/run/root/1000) and run
> the test application after some loopback it gives segmentation fault in
GPU
> driver. I would like to know what difference does it make if I export
> XDG_RUNTIME_DIR or not? Why the different behavior?

XDG_RUNTIME_DIR is where the Wayland socket will be, so if the
compositor and the client have different runtime dirs, the client
should usually fail to connect.

Is it possible that you get a fallback to X11 via Xwayland?

Are you sure you don't mean /run/user/1000?

XDG_RUNTIME_DIR may also be used for allocating wl_shm buffers - are
you running out of disk space there? (The space will hopefully get
freed as soon as the client reserving it dies.)


Thanks,
pq

> [1] gst-launch-1.0 filesrc location=/home/root/VIDEO.MP4 typefind=true !
> video/quicktime ! aiurdemux ! queue max-size-time=0 ! vpudec frame-plus=1
> frame-drop=false ! glimagesink
>
>
>
> Regards,
>
> Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

wayland/weston 1.9.0 and glimagesingk gstreamer wayland sink query with i.MX6

[Vikas Patil]

Dear All,



When I run simple video application (which pause and play gstreamer
pipeline continuously) based on following pipeline [1] with  weston 1.9.0  and
glimagesink (part of gstreamer1.0-plugins-bad 1.6.0 package) on i.MX6 based
platform and Linux 4.1 without exporting (export
XDG_RUNTIME_DIR=/var/run/root/1000) then it works fine and runs as long as
I want.



However when I export (export XDG_RUNTIME_DIR=/var/run/root/1000) and run
the test application after some loopback it gives segmentation fault in GPU
driver. I would like to know what difference does it make if I export
XDG_RUNTIME_DIR or not? Why the different behavior?



[1] gst-launch-1.0 filesrc location=/home/root/VIDEO.MP4 typefind=true !
video/quicktime ! aiurdemux ! queue max-size-time=0 ! vpudec frame-plus=1
frame-drop=false ! glimagesink



Regards,

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

Re: weston sometime fails to start using systemd unit file

[Vikas Patil]

Hi Daniel,

Any clue/inputs after looking at the logs?

Regards,
Vikash

On Wed, Jan 11, 2017 at 10:55 AM, Vikas Patil <vikasmpa...@gmail.com> wrote:

> Hi Daniel,
>
> Thanks a lot for your quick reply. See comments below.
>
> On Tue, Jan 10, 2017 at 9:28 PM, Daniel Díaz Rodríguez <
> daniel.d...@linaro.org> wrote:
>
>> Hello!
>>
>>
>> On 10 January 2017 at 06:39, Vikas Patil <vikasmpa...@gmail.com> wrote:
>> >> We are starting weston (1.9.0) using below systemd unit file of type
>> notify
>> >> (backported sd_notify related changes from weston 1.11.0 to weston
>> 1.9.0).
>> >> It works well with i.MX6 (NXP, fbdev backend) based platform, however
>> with
>> >> Jacinto (TI, drm backend) based platform sometimes it fails to start
>> and
>> >> sometime it works after reboot. It always works if we start weston
>> service
>> >> manually after platform boots up using “systemctl”.
>> >> Is there anyone encountered this issue? Any suggestion/inputs to fix
>> this?
>>
>> > We have seen this, as the DRM device is not readily available by the
>> > time Weston launches. Our service unit is a bit different [1], but the
>> > approach that proved most convenient was to use this udev rule to call
>> > for Weston:
>>   > https://github.com/96boards/meta-96boards/blob/master/recipe
>> s-graphics/wayland/weston-init/71-weston-drm.rules
>> <https://github.com/96boards/meta-96boards/blob/master/recipes-graphics/wayland/weston-init/71-weston-drm.rules>
>
>
> I have tried this udev rule and unfortunately it didn't help. I have added
> the rule in "/etc/udev/rules.d/localextra.rules" file on target. Then I
> have another service as below to trigger it.
>
> root@linux-1:~# cat /lib/systemd/system/udevd.service
>
> [Unit]
> Description=udevd service
> DefaultDependencies=false
>
> [Service]
> Type=forking
> ExecStart=/lib/systemd/systemd-udevd --daemon
> ExecStartPost=/bin/udevadm test /sys/devices/platform/omapdrm.0/drm/card0
>
>  Attached here the weston log and service file when it fails. (what see is
> , weston starts but within four or five seconds it stops)
>
> How could I find what issue/problem it is having? Is there any more logs
> from systemd I need to enable?
>
>
> Regards,
> Vikash
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: weston sometime fails to start using systemd unit file

[Vikas Patil]

Hi Daniel,

Thanks a lot for your quick reply. See comments below.

On Tue, Jan 10, 2017 at 9:28 PM, Daniel Díaz Rodríguez <
daniel.d...@linaro.org> wrote:

> Hello!
>
>
> On 10 January 2017 at 06:39, Vikas Patil <vikasmpa...@gmail.com> wrote:
> >> We are starting weston (1.9.0) using below systemd unit file of type
> notify
> >> (backported sd_notify related changes from weston 1.11.0 to weston
> 1.9.0).
> >> It works well with i.MX6 (NXP, fbdev backend) based platform, however
> with
> >> Jacinto (TI, drm backend) based platform sometimes it fails to start and
> >> sometime it works after reboot. It always works if we start weston
> service
> >> manually after platform boots up using “systemctl”.
> >> Is there anyone encountered this issue? Any suggestion/inputs to fix
> this?
>
> > We have seen this, as the DRM device is not readily available by the
> > time Weston launches. Our service unit is a bit different [1], but the
> > approach that proved most convenient was to use this udev rule to call
> > for Weston:
>   > https://github.com/96boards/meta-96boards/blob/master/
> recipes-graphics/wayland/weston-init/71-weston-drm.rules
> <https://github.com/96boards/meta-96boards/blob/master/recipes-graphics/wayland/weston-init/71-weston-drm.rules>


I have tried this udev rule and unfortunately it didn't help. I have added
the rule in "/etc/udev/rules.d/localextra.rules" file on target. Then I
have another service as below to trigger it.

root@linux-1:~# cat /lib/systemd/system/udevd.service

[Unit]
Description=udevd service
DefaultDependencies=false

[Service]
Type=forking
ExecStart=/lib/systemd/systemd-udevd --daemon
ExecStartPost=/bin/udevadm test /sys/devices/platform/omapdrm.0/drm/card0

 Attached here the weston log and service file when it fails. (what see is
, weston starts but within four or five seconds it stops)

How could I find what issue/problem it is having? Is there any more logs
from systemd I need to enable?


Regards,
Vikash


weston.service
Description: Binary data


weston_fail.log
Description: Binary data
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

weston sometime fails to start using systemd unit file

[Vikas Patil]

Dear All,

We are starting weston (1.9.0) using below systemd unit file of type notify
(backported sd_notify related changes from weston 1.11.0 to weston 1.9.0).
It works well with i.MX6 (NXP, fbdev backend) based platform, however with
Jacinto (TI, drm backend) based platform sometimes it fails to start and
sometime it works after reboot. It always works if we start weston service
manually after platform boots up using “systemctl”.

Is there anyone encountered this issue? Any suggestion/inputs to fix this?


Weston.service file:

[Unit]
Description=weston (wayland compositor)
DefaultDependencies=false
After=pvrinit.service

[Service]
#Type=simple
Type=notify
NotifyAccess=all
WatchdogSec=60s
ExecStartPre=/bin/mkdir -p /var/run/root/1000
ExecStartPre=/bin/chmod 0700 /var/run/root/1000
ExecStart=/usr/bin/weston --tty=1 --idle-time=0 --backend=drm-backend.so
--connector=36 --log=/tmp/weston.log

# --- Exec options ---
Environment=XDG_RUNTIME_DIR=/var/run/root/1000
EnvironmentFile=-/tmp/GlobalSystemSettingsEnvironment
EnvironmentFile=-/tmp/GlobalSPOTOverrideEnvironment

# EOF


Below is the status of service when fails and when starts successfully.

Failure:

root@linux_demo0:~# systemctl status weston -l
? weston.service - weston (wayland compositor)
   Loaded: loaded (/lib/systemd/system/weston.service; static; vendor
preset: enabled)
   Active: inactive (dead) since Thu 1970-01-01 00:00:13 UTC; 4s ago
  Process: 760 ExecStart=/usr/bin/weston --tty=1 --idle-time=0
--backend=drm-backend.so --connector=36 --log=/tmp/weston.log (code=exited,
status=0/SUCCESS)
  Process: 755 ExecStartPre=/bin/chmod 0700 /var/run/root/1000
(code=exited, status=0/SUCCESS)
  Process: 744 ExecStartPre=/bin/mkdir -p /var/run/root/1000 (code=exited,
status=0/SUCCESS)
 Main PID: 760 (code=exited, status=0/SUCCESS)

Jan 01 00:00:05 linux_demo0 weston[760]: failed to load module:
/usr/lib/gbm/gbm_dri.so: cannot open shared object file: No such file or
directory
Jan 01 00:00:05 linux_demo0 weston[760]: failed to load module:
/usr/lib/gbm/gbm_gallium_drm.so: cannot open shared object file: No such
file or directory
Jan 01 00:00:05 linux_demo0 weston[760]: loaded module : gbm_pvr.so
Jan 01 00:00:05 linux_demo0 weston[760]: found valid GBM backend :
gbm_pvr.so
Jan 01 00:00:12 linux_demo0 systemd[1]: weston.service: Got notification
message from PID 760 (STOPPING=1)
Jan 01 00:00:12 linux_demo0 systemd[1]: weston.service: Changed running ->
stop-sigterm
Jan 01 00:00:13 linux_demo0 systemd[1]: weston.service: Child 760 belongs
to weston.service
Jan 01 00:00:13 linux_demo0 systemd[1]: weston.service: Main process
exited, code=exited, status=0/SUCCESS
Jan 01 00:00:13 linux_demo0 systemd[1]: weston.service: Changed
stop-sigterm -> dead
Jan 01 00:00:13 linux_demo0 systemd[1]: weston.service: cgroup is empty


Success:

root@linux_demo0:~# systemctl status weston -l
? weston.service - weston (wayland compositor)
   Loaded: loaded (/lib/systemd/system/weston.service; static; vendor
preset: enabled)
   Active: active (running) since Thu 1970-01-01 00:00:15 UTC; 17s ago
  Process: 752 ExecStartPre=/bin/chmod 0700 /var/run/root/1000
(code=exited, status=0/SUCCESS)
  Process: 746 ExecStartPre=/bin/mkdir -p /var/run/root/1000 (code=exited,
status=0/SUCCESS)
 Main PID: 761 (weston)
   CGroup: /system.slice/weston.service
   mq761 /usr/bin/weston --tty=1 --idle-time=0
--backend=drm-backend.so --connector=36 --log=/tmp/weston.log

Jan 01 00:00:15 linux_demo0 systemd[1]: weston.service: Changed start-pre
-> start
Jan 01 00:00:15 linux_demo0 systemd[761]: weston.service: Executing:
/usr/bin/weston --tty=1 --idle-time=0 --backend=drm-backend.so
--connector=36 --log=/tmp/weston.log
Jan 01 00:00:15 linux_demo0 weston[761]: failed to load module:
/usr/lib/gbm/gbm_dri.so: cannot open shared object file: No such file or
directory
Jan 01 00:00:15 linux_demo0 weston[761]: failed to load module:
/usr/lib/gbm/gbm_gallium_drm.so: cannot open shared object file: No such
file or directory
Jan 01 00:00:15 linux_demo0 weston[761]: loaded module : gbm_pvr.so
Jan 01 00:00:15 linux_demo0 weston[761]: found valid GBM backend :
gbm_pvr.so
Jan 01 00:00:15 linux_demo0 systemd[1]: weston.service: Got notification
message from PID 761 (READY=1)
Jan 01 00:00:15 linux_demo0 systemd[1]: weston.service: Changed start ->
running
Jan 01 00:00:15 linux_demo0 systemd[1]: weston.service: Job
weston.service/start finished, result=done
Jan 01 00:00:15 linux_demo0 systemd[1]: Started weston (wayland compositor).
Jan 01 00:00:45 linux_demo0 systemd[1]: weston.service: Got notification
message from PID 761 (WATCHDOG=1)


Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: starting weston using systemd on tty=1 query

[Vikas Patil]

I added following line in weston.service but still it failed.

Conflicts=getty@tty1.service


root@linux123:~# systemctl status weston -l
? weston.service - weston (wayland compositor)
   Loaded: loaded (/lib/systemd/system/weston.service; static; vendor
preset: enabled)
   Active: inactive (dead) since Thu 1970-01-01 00:00:17 UTC; 46 years
8 months ago
  Process: 920 ExecStart=/usr/bin/weston --tty=1 --idle-time=0
--backend=drm-backend.so --connector=36 --log=/tmp/weston.log
(code=exited, status=0/SUCCESS)
  Process: 915 ExecStartPre=/bin/chmod 0700 /var/run/root/1000
(code=exited, status=0/SUCCESS)
  Process: 744 ExecStartPre=/bin/mkdir -p /var/run/root/1000
(code=exited, status=0/SUCCESS)
 Main PID: 920 (code=exited, status=0/SUCCESS)

Jan 01 00:00:16 mmt2020 systemd[1]: Started weston (wayland compositor).
Jan 01 00:00:16 mmt2020 systemd[1]: weston.service: Failed to send
unit change signal for weston.service: Transport endpoint is not
connected
Jan 01 00:00:17 mmt2020 systemd[1]: weston.service: Got notification
message from PID 920 (STOPPING=1)
Jan 01 00:00:17 mmt2020 systemd[1]: weston.service: Failed to send
unit change signal for weston.service: Transport endpoint is not
connected
Jan 01 00:00:17 mmt2020 systemd[1]: weston.service: Main process
exited, code=exited, status=0/SUCCESS
Jan 01 00:00:17 mmt2020 systemd[1]: weston.service: Changed stop-sigterm -> dead

Regards,
Vikash

On Wed, Oct 5, 2016 at 2:21 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
> Dear All,
>
> I am working on to start weston on tty=1 using the systemd, however it
> fails to start on boot-up. If I launch weston after bootup using
> "systemd start weston" then it works but not with the bootup. If I use
> tty=2 then it work on bootup. systemd version is 225.
>
> Could you anyone explain why it fails with tty=1 on bootup and works
> with tty=2? Is there anyway I can start it on tty=1? Is it fine if I
> start it with tty=2?
>
> Here are the log for failure:
>
> root@linux123:~# systemctl status weston -l
> ? weston.service - weston (wayland compositor)
>Loaded: loaded (/lib/systemd/system/weston.service; static; vendor
> preset: enabled)
>Active: inactive (dead) since Fri 2016-09-30 10:00:44 UTC; 51s ago
>   Process: 1284 ExecStart=/usr/bin/weston --tty=1 --idle-time=0
> --backend=drm-backend.so --connector=36 --log=/tmp/weston.log
> (code=exited, status=0/SUCCESS)
>   Process: 1278 ExecStartPre=/bin/chmod 0700 /var/run/root/1000
> (code=exited, status=0/SUCCESS)
>   Process: 1271 ExecStartPre=/bin/mkdir -p /var/run/root/1000
> (code=exited, status=0/SUCCESS)
>  Main PID: 1284 (code=exited, status=0/SUCCESS)
>
> Sep 30 10:00:43 mmt2020 systemd[1]: weston.service: Got notification
> message from PID 1284 (STOPPING=1)
> Sep 30 10:00:43 mmt2020 systemd[1]: weston.service: Changed running ->
> stop-sigterm
> Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: Child 1284 belongs
> to weston.service
> Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: Main process
> exited, code=exited, status=0/SUCCESS
> Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: Changed stop-sigterm -> 
> dead
> Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: cgroup is empty
>
> Here is my weston.service file
>
> [Unit]
> Description=weston (wayland compositor)
> DefaultDependencies=false
> Requires=pvrinit.service udevd.service
> After=pvrinit.service udevd.service
>
> [Service]
> Type=notify
> NotifyAccess=all
> WatchdogSec=20s
> ExecStartPre=/bin/mkdir -p /var/run/root/1000
> ExecStartPre=/bin/chmod 0700 /var/run/root/1000
> ExecStart=/usr/bin/weston --tty=1 --idle-time=0
> --backend=drm-backend.so --connector=36 --log=/tmp/weston.log
>
> # --- Exec options ---
> Nice=-20
> Environment=XDG_RUNTIME_DIR=/var/run/root/1000
> EnvironmentFile=-/tmp/GlobalSystemSettingsEnvironment
> EnvironmentFile=-/tmp/GlobalSPOTOverrideEnvironment
>
> # --- Kill options ---
>
> # EOF
>
>
> Here are the output for "dmesg | grep tty"
>
> root@linux123:~# dmesg | grep tty
> [4.863360] systemd[698]: Spawned
> /lib/systemd/system-generators/systemd-getty-generator as 703.
> [4.875864] systemd-getty-generator[703]: Automatically adding
> serial getty for /dev/ttyO2.
> [4.881230] systemd[698]:
> /lib/systemd/system-generators/systemd-getty-generator succeeded.
> [5.021443] systemd[1]: getty@tty1.service: Installed new job
> getty@tty1.service/start as 61
> [5.021690] systemd[1]: system-getty.slice: Installed new job
> system-getty.slice/start as 62
> [5.021819] systemd[1]: getty.target: Installed new job
> getty.target/start as 60
> [5.022199] systemd[1]: system-serial\x2dgetty.slice: Installed new
> job system-serial\x2dgetty.slice/start as 65
> [   

starting weston using systemd on tty=1 query

[Vikas Patil]

Dear All,

I am working on to start weston on tty=1 using the systemd, however it
fails to start on boot-up. If I launch weston after bootup using
"systemd start weston" then it works but not with the bootup. If I use
tty=2 then it work on bootup. systemd version is 225.

Could you anyone explain why it fails with tty=1 on bootup and works
with tty=2? Is there anyway I can start it on tty=1? Is it fine if I
start it with tty=2?

Here are the log for failure:

root@linux123:~# systemctl status weston -l
? weston.service - weston (wayland compositor)
   Loaded: loaded (/lib/systemd/system/weston.service; static; vendor
preset: enabled)
   Active: inactive (dead) since Fri 2016-09-30 10:00:44 UTC; 51s ago
  Process: 1284 ExecStart=/usr/bin/weston --tty=1 --idle-time=0
--backend=drm-backend.so --connector=36 --log=/tmp/weston.log
(code=exited, status=0/SUCCESS)
  Process: 1278 ExecStartPre=/bin/chmod 0700 /var/run/root/1000
(code=exited, status=0/SUCCESS)
  Process: 1271 ExecStartPre=/bin/mkdir -p /var/run/root/1000
(code=exited, status=0/SUCCESS)
 Main PID: 1284 (code=exited, status=0/SUCCESS)

Sep 30 10:00:43 mmt2020 systemd[1]: weston.service: Got notification
message from PID 1284 (STOPPING=1)
Sep 30 10:00:43 mmt2020 systemd[1]: weston.service: Changed running ->
stop-sigterm
Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: Child 1284 belongs
to weston.service
Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: Main process
exited, code=exited, status=0/SUCCESS
Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: Changed stop-sigterm -> dead
Sep 30 10:00:44 mmt2020 systemd[1]: weston.service: cgroup is empty

Here is my weston.service file

[Unit]
Description=weston (wayland compositor)
DefaultDependencies=false
Requires=pvrinit.service udevd.service
After=pvrinit.service udevd.service

[Service]
Type=notify
NotifyAccess=all
WatchdogSec=20s
ExecStartPre=/bin/mkdir -p /var/run/root/1000
ExecStartPre=/bin/chmod 0700 /var/run/root/1000
ExecStart=/usr/bin/weston --tty=1 --idle-time=0
--backend=drm-backend.so --connector=36 --log=/tmp/weston.log

# --- Exec options ---
Nice=-20
Environment=XDG_RUNTIME_DIR=/var/run/root/1000
EnvironmentFile=-/tmp/GlobalSystemSettingsEnvironment
EnvironmentFile=-/tmp/GlobalSPOTOverrideEnvironment

# --- Kill options ---

# EOF


Here are the output for "dmesg | grep tty"

root@linux123:~# dmesg | grep tty
[4.863360] systemd[698]: Spawned
/lib/systemd/system-generators/systemd-getty-generator as 703.
[4.875864] systemd-getty-generator[703]: Automatically adding
serial getty for /dev/ttyO2.
[4.881230] systemd[698]:
/lib/systemd/system-generators/systemd-getty-generator succeeded.
[5.021443] systemd[1]: getty@tty1.service: Installed new job
getty@tty1.service/start as 61
[5.021690] systemd[1]: system-getty.slice: Installed new job
system-getty.slice/start as 62
[5.021819] systemd[1]: getty.target: Installed new job
getty.target/start as 60
[5.022199] systemd[1]: system-serial\x2dgetty.slice: Installed new
job system-serial\x2dgetty.slice/start as 65
[5.022456] systemd[1]: serial-getty@ttyS0.service: Installed new
job serial-getty@ttyS0.service/start as 63
[5.022829] systemd[1]: serial-getty@ttyO2.service: Installed new
job serial-getty@ttyO2.service/start as 66
[5.022908] systemd[1]: dev-ttyS0.device: Installed new job
dev-ttyS0.device/start as 64
[5.022977] systemd[1]: dev-ttyO2.device: Installed new job
dev-ttyO2.device/start as 67
[5.242611] systemd[1]: system-serial\x2dgetty.slice changed dead -> active
[5.242637] systemd[1]: system-serial\x2dgetty.slice: Job
system-serial\x2dgetty.slice/start finished, result=done
[5.242665] systemd[1]: Created slice system-serial\x2dgetty.slice.
[5.542780] systemd[1]: system-getty.slice changed dead -> active
[5.542807] systemd[1]: system-getty.slice: Job
system-getty.slice/start finished, result=done
[5.542839] systemd[1]: Created slice system-getty.slice.
[8.252350] systemd[1]:
sys-devices-platform-4400.ocp-4806c000.serial-tty-ttyO1.device:
Changed dead -> plugged
[9.234335] systemd[1]: serial-getty@ttyO2.service: Job
serial-getty@ttyO2.service/start finished, result=done
[9.512323] systemd[1]: getty@tty1.service:
ConditionPathExists=/dev/tty0 succeeded.
[9.532327] systemd[1]: getty@tty1.service: Forked /sbin/agetty as 1310
[9.572372] systemd[1]: getty@tty1.service: Job
getty@tty1.service/start finished, result=done
[9.942423] systemd[1]: Sent message type=signal sender=n/a
destination=n/a
object=/org/freedesktop/systemd1/unit/dev_2dttyO1_2edevice
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=1 reply_cookie=0 error=n/a
[9.952428] systemd[1]: Sent message type=signal sender=n/a
destination=n/a
object=/org/freedesktop/systemd1/unit/sys_2ddevices_2dplatform_2d4400_2eocp_2d4806c000_2eserial_2dtty_2dttyO1_2edevice
interface=org.freedesktop.DBus.Properties member=PropertiesChanged
cookie=3 reply_cookie=0 error=n/a

Understanding Multi Display Support with Wayland/Weston

[Vikas Patil]

Dear All,

I am trying to understand multi display support  with wayland/weston
in any of the following mode with drm-backend and ivi-shell. Planning
to use TI soc (Jacinto 6, DRA7XX) with linux to test multi display
(dual).

It would be great help if you could give inputs/information/suggest on this.

1. Extended Mode.
- This seems to be available from guide from TI [1]. I assume this
will be running one instance of weston with desktop-shell.
- Is this posible with ivi-shell?

2. Clone Mode.
- Is this possible? How to configure this?

3. Independent Driving.
- Is this possible?
- Are two instance of weston possible?

Anyone here tried wayland/weston with multiple display in any of the
above configuration?

Thanking you all in advance.

[1] 
processors.wiki.ti.com/.../Processor_SDK_Linux_Automotive_Software_Developers_Guide

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Two wayland connection in single process context

[Vikas Patil]

On Fri, Jul 29, 2016 at 4:53 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 29 Jul 2016 15:03:39 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>>
>> > On Wed, 27 Jul 2016 17:06:04 +0530
>> > Vikas Patil <vikasmpa...@gmail.com> wrote:
>> >
>> >> Dear All,
>> >>
>> >> Could you comment/suggest on following approach of using two different
>> >> wayland connection in single process?
>> >>
>> >> First wayland connection for creating wl_shm backed wayland surface
>> >> for receiving touch inputs in main thread or as separate thread. Like
>> >> simple-touch.c example but without painting and transparent.
>> >>
>> >> Second wayland connection for another egl wayland surface for
>> >> rendering in shared library which will be loaded by above application.
>> >> Like simple-egl.c example.
>> >
>> > Hi,
>> >
>> > if you never want your first connection to handle input events on the
>> > surface created on the second connection, I suppose it would work. You
>> > also will not be able position your surfaces from the different
>> > connections relative to each other at all.
>> >
>> > The main thing to remember is that *everything* is private to a
>> > connection. If you create a wl_surface on one connection, it is as if
>> > it does not exist at all for any other connection. It does not matter
>> > if the connections come from the same thread, process, or not.
>> >
>> > If you expect any sort of interoperability, you *must* use the same
>> > connection for everything. Opening a second connection from the same
>> > program to the same server is practically always a design mistake.
>> >
>> > Of course, one could make Wayland extensions to work around this, but
>> > don't go there.
>> >
>> > So, in short: don't do it.
>> >
>> >> Will this work? Is it this the right way to do it or is there any
>> >> other mechanism available for such requirement?
>> >
>> > What do you want to achieve?
>> > You didn't explain what you really want to do.
>> >
>>
>> I have a video rendering library (which handles all media related
>> functions too) which is used by application, and that library make use
>> of first wayland connection and don't handle the touch events as there
>> is no way to pass that information to application so thinking to make
>> transparent wayland surface on top of wayland surface to which the
>> video is rendered by library to handle the touch events by creating
>> second wayland connection in application.
>
> There is no quick solution AFAIK.
>
> You have to fix both the application and the media library to become
> Wayland-friendly. The minimal starting point is:
>
> - the application (or its toolkit) opens the one Wayland connection
> - the application passes the open Wayland connection to the library
> - the library does not open new Wayland connections
>

Thanks a lot for putting your detail thought here.

Do you know if clients/nested.c, clients/nested-client.c mentioned by
"Armin Krezović " is helpful here in anyways? When I tried to run it
it just displayed black window? What functionality it demos?

What do you mean by passing "wayland connection" or passing
wl_surface? Does it mean passing the object handle with some kind of
IPC mechanism (possibly UNIX domain socket)?

Do you know any such implementation available for reference? I don't
have the code for our media library so I could try to create simple
POC for this first?


> Once you have done that, you have several options to choose from. I can
> think of at least these:
>
> - The application creates the wl_surface and tells the media library to
>   use it, or
> - the media library creates the wl_surface, and tells the app about it.
> - You handle input on the wl_surface that is being used by media
>   library either in the application, or
> - add media library API to handle or export input events.
> - Or you have two surfaces, one being the sub-surface for the other,
>   the media library uses one and the application uses the other for
>   input.
>
> If the media library can draw a complete window, it would be best to
> deal with just one wl_surface.
>
> If you have to have different wl_surfaces for input and output, you
> would use sub-surface protocol to tie them together. If the media
> library only draws video, you can set the i

Re: Two wayland connection in single process context

[Vikas Patil]

On Fri, Jul 29, 2016 at 1:17 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:

> On Wed, 27 Jul 2016 17:06:04 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> Dear All,
>>
>> Could you comment/suggest on following approach of using two different
>> wayland connection in single process?
>>
>> First wayland connection for creating wl_shm backed wayland surface
>> for receiving touch inputs in main thread or as separate thread. Like
>> simple-touch.c example but without painting and transparent.
>>
>> Second wayland connection for another egl wayland surface for
>> rendering in shared library which will be loaded by above application.
>> Like simple-egl.c example.
>
> Hi,
>
> if you never want your first connection to handle input events on the
> surface created on the second connection, I suppose it would work. You
> also will not be able position your surfaces from the different
> connections relative to each other at all.
>
> The main thing to remember is that *everything* is private to a
> connection. If you create a wl_surface on one connection, it is as if
> it does not exist at all for any other connection. It does not matter
> if the connections come from the same thread, process, or not.
>
> If you expect any sort of interoperability, you *must* use the same
> connection for everything. Opening a second connection from the same
> program to the same server is practically always a design mistake.
>
> Of course, one could make Wayland extensions to work around this, but
> don't go there.
>
> So, in short: don't do it.
>
>> Will this work? Is it this the right way to do it or is there any
>> other mechanism available for such requirement?
>
> What do you want to achieve?
> You didn't explain what you really want to do.
>

I have a video rendering library (which handles all media related
functions too) which is used by application, and that library make use
of first wayland connection and don't handle the touch events as there
is no way to pass that information to application so thinking to make
transparent wayland surface on top of wayland surface to which the
video is rendered by library to handle the touch events by creating
second wayland connection in application.

I tried creating and handling touch event (similar to simple-touch.c)
with second wayland connection after the application loads the library
but it gave me following errors. So I thought it might not be
possible. Also I think you hinted same here
https://lists.freedesktop.org/archives/wayland-devel/2015-September/024211.html

Error communicating with wayland: Protocol error
Error communicating with wayland: Protocol error
Error communicating with wayland: Protocol error
Error communicating with wayland: Protocol error
Error communicating with wayland: Protocol error


Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Two wayland connection in single process context

[Vikas Patil]

Dear All,

Could you comment/suggest on following approach of using two different
wayland connection in single process?

First wayland connection for creating wl_shm backed wayland surface
for receiving touch inputs in main thread or as separate thread. Like
simple-touch.c example but without painting and transparent.

Second wayland connection for another egl wayland surface for
rendering in shared library which will be loaded by above application.
Like simple-egl.c example.

Will this work? Is it this the right way to do it or is there any
other mechanism available for such requirement?

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Touch events not reviving with wayland-ivi-extenssion 1.4.0 and wayland video sink

[Vikas Patil]

Dear All,

Seeing the below wayland log without above workaround focus is going 0
to surface. I think it means surface is failing to grab the touch
focus. What could be the reasons of focus not getting setup?

I think this [3687363.407] ivi_input@19.input_focus(90, 4, 0) need to
be [3687363.407] ivi_input@19.input_focus(90, 4, 1) for touch to work.
any ideas here?



[3687298.588]  -> wl_surface@9.commit()
[3687314.601] wl_buffer@30.release()
[3687314.718] wl_callb...@29.done(299298)
[3687314.793]  -> wl_surface@12.frame(new id wl_callback@29)
[3687314.910]  -> wl_surface@12.attach(wl_buffer@28, 0, 0)
[3687315.022]  -> wl_surface@12.damage(0, 0, 800, 480)
[3687315.140]  -> wl_surface@12.commit()
[3687340.439] wl_display@1.delete_id(14)
[3687340.620] wl_display@1.delete_id(26)
[3687340.690] wl_display@1.delete_id(29)
[3687340.811] wl_callb...@26.done(299368)
[3687341.024]  -> wl_surface@12.frame(new id wl_callback@26)
[3687363.407] ivi_input@19.input_focus(90, 4, 0)
[3687366.986]  -> wl_compositor@3.create_region(new id wl_region@14)
[3687367.165]  -> wl_reg...@14.add(0, 0, 800, 480)
[3687367.286]  -> wl_surface@12.set_opaque_region(wl_region@14)
[3687367.347]  -> wl_region@14.destroy()
[3687367.394]  -> wl_surface@9.commit()
[3687376.888] wl_buffer@27.release()
[3687376.987] wl_callb...@29.done(299368)
[3687377.077]  -> wl_surface@12.frame(new id wl_callback@29)
[3687377.161]  -> wl_surface@12.attach(wl_buffer@30, 0, 0)


Thanks & Regards,
Vikash

On Tue, Dec 15, 2015 at 8:24 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
> If I force to pass the if condition as follows using the surface id
> even though surfaces doesn't match, it is working. Does this might be
> due to the way I created the surface 90? Surface 90 also has
> subsurface, does it anyway related to subsurface?
>
> Alos "grab->touch->focus->surface" what this surface is and who creates it?
>
> surfID = interface->get_id_of_surface(surf_ctx->layout_surface);
>
> /* Touches set touch focus */
>
> if (grab->touch->num_tp == 1) {
>
> if (surf == grab->touch->focus->surface ||  surfID == 90) {
>
> surf_ctx->focus |= ILM_INPUT_DEVICE_TOUCH;
>
> send_input_focus(seat->input_ctx,
>
>
> interface->get_id_of_surface(surf_ctx->layout_surface),
>
>  ILM_INPUT_DEVICE_TOUCH, ILM_TRUE);
>
> }
>
>
> Thanks & Regards,
> Vikash
>
> On Mon, Dec 14, 2015 at 8:53 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
>> I am hitting else part of below code for this issue. Any ideas?
>>
>> touch_grab_down() from ivi-input-controller.c
>>
>>  /* Touches set touch focus */
>> if (grab->touch->num_tp == 1) {
>> if (surf == grab->touch->focus->surface) {
>> surf_ctx->focus |= ILM_INPUT_DEVICE_TOUCH;
>> send_input_focus(seat->input_ctx,
>>
>> interface->get_id_of_surface(surf_ctx->layout_surface),
>>  ILM_INPUT_DEVICE_TOUCH, ILM_TRUE);
>> } else {
>> surf_ctx->focus &= ~ILM_INPUT_DEVICE_TOUCH;
>> <--
>> send_input_focus(seat->input_ctx,
>>
>> interface->get_id_of_surface(surf_ctx->layout_surface),
>>  ILM_INPUT_DEVICE_TOUCH, ILM_FALSE);
>> }
>> }
>>
>> /* This code below is slightly redundant, since we have already
>>  * decided only one surface has touch focus */
>> if (!(surf_ctx->focus & ILM_INPUT_DEVICE_TOUCH))
>> continue;
>> <-
>>
>>
>> Thanks & Regards,
>> Vikash
>>
>> On Mon, Dec 14, 2015 at 3:25 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
>>> Sorry. Forgot to attach the log file. Attached here.
>>>
>>> Thanks & Regards,
>>> Vikas
>>>
>>> On Mon, Dec 14, 2015 at 3:24 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
>>>> Hi Eugen Friedrich
>>>>
>>>> Thanks a lot for your quick reply.
>>>>
>>>> Attached here the file with WAYLAND_DEBUG=1 log when the gstreamer
>>>> plug-in is in use. I can see "ivi_input@18.input_focus(90, 4, 0)" for
>>>> the surface from plug-in but no touch events.
>>>>
>>>> Here is the output of APIs
>>>>
>>>> root@linux-9939-a1:~# LayerMana

eglSwapBuffer blocks without any shell surface query!

[Vikas Patil]

Dear All,

What if I don't use any shell/shell surface in GLES/EGL based
application with wayland/weston? Will eglSwapBuffer blocks in that
case? Is using any shell surface must?

I am fine if application doesn't display but it should run and not
block without shell surface. I am trying to understand behavior of
eglSwapBuffer and why it is blocking?

Attached here example application which doesn't use any shell surface
and just renders in egl surface, however with this I am seeing
application gets blocked in eglSwapBuffer with i.MX6/Linux platform.


Thanks & Regards,
Vikash
/*
* Example Application on How to use Wayland and Wayland-ivi-extension
* (i.e. ILM APIs). This application draws smooth shaded rotating triangle
* on display.
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 
#include 
#include 
#include 

//#define  LM_SUPPORT 1 //enable this line for layer manager

#ifdef LM_SUPPORT
#include "ilm/ilm_control.h"
#include "ilm/ilm_client.h"
#endif 

#include "weston/platform.h"

#define WL_UNUSED(A) (A)=(A)

//
#define CHECK_EGL_ERROR(FUNC, STAT) \
STAT = eglGetError();   \
if (STAT != EGL_SUCCESS){   \
fprintf(stderr, "[ERROR] %s failed: %d\n", FUNC, STAT); \
return 1;   \
}

//

GLuint vert;
GLuint frag;
GLuint program;

volatile sig_atomic_t running = 1;

struct wl_display*wlDisplay = NULL;
struct wl_registry*   wlRegistry= NULL;
struct wl_compositor* wlCompositor= NULL;
struct wl_seat*   wlSeat= NULL;
struct wl_pointer*wlPointer= NULL;
struct wl_keyboard*   wlKeyboard= NULL;
struct wl_touch*  wlTouch= NULL;
struct serverinfo*wlServerInfo= NULL;

struct wl_pointer_listener*  wlPointerListener= NULL;
struct wl_keyboard_listener* wlKeyboardListener= NULL;
struct wl_touch_listener*wlTouchListener= NULL;

struct wl_egl_window* wlEglWindow= NULL;
struct wl_surface* wlSurface= NULL;

EGLDisplayeglDisplay= NULL;
EGLConfig eglConfig= NULL;
EGLSurfaceeglSurface= NULL;
EGLContexteglContext= NULL;
	
int   width = 800;
int   height = 480;
#ifdef LM_SUPPORT
t_ilm_layer   ilmLayerId = 5000;
t_ilm_surface ilmSurfaceId = 55;
#endif 

struct GLWindow {
		GLuint rotation_uniform;
		GLuint pos;
		GLuint col;
		uint32_t benchmark_time, frames;
};

static const char *vert_shader_text =
	"uniform mat4 rotation;\n"
	"attribute vec4 pos;\n"
	"attribute vec4 color;\n"
	"varying vec4 v_color;\n"
	"void main() {\n"
	"  gl_Position = rotation * pos;\n"
	"  v_color = color;\n"
	"}\n";

static const char *frag_shader_text =
	"precision mediump float;\n"
	"varying vec4 v_color;\n"
	"void main() {\n"
	"  gl_FragColor = v_color;\n"
	"}\n";


static void
global_registry_handler(void* data, struct wl_registry* registry, uint32_t id,
			const char* interface, uint32_t version)
{
	printf("Got a registry event for %s id %d\n", interface, id);
   // WL_UNUSED(version);
do
	{
		if (!strcmp(interface, "wl_compositor"))
		{
wlCompositor =
(struct wl_compositor*) wl_registry_bind(registry, id,
		_compositor_interface, 1);
break;
}
		
} while (0);
}

static void
global_registry_remover(void *data, struct wl_registry *registry, uint32_t id)
{
printf("Got a registry losing event for %d\n", id);
}

static struct wl_registry_listener registryListener = {
   global_registry_handler,
   global_registry_remover
};

static int
init_egl()
{
EGLint eglStat = EGL_SUCCESS;
EGLint major, minor, n, count, i, size;
EGLConfig *configs;
//int nConfig;
EGLBoolean ret;

EGLint configAttribs[] = {
EGL_SURFACE_TYPE, EGL_WINDOW_BIT,
EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
EGL_RED_SIZE,   8,
EGL_GREEN_SIZE, 8,
EGL_BLUE_SIZE,  8,
EGL_ALPHA_SIZE, 8,
//EGL_SAMPLE_BUFFERS, 1,
//EGL_SAMPLES,2,
EGL_NONE,
};
EGLint contextAttribs[] = {
EGL_CONTEXT_CLIENT_VERSION, 2,
EGL_NONE,
};

eglDisplay = eglGetDisplay((EGLNativeDisplayType)wlDisplay);
   // eglDisplay  = weston_platform_get_egl_display(EGL_PLATFORM_WAYLAND_KHR,
		//wlDisplay, NULL);
CHECK_EGL_ERROR("eglGetDisplay", eglStat);

if (!eglInitialize(eglDisplay, , )){
CHECK_EGL_ERROR("eglInitialize", eglStat);
}

eglBindAPI(EGL_OPENGL_ES_API);
CHECK_EGL_ERROR("eglBindAPI", eglStat);

#if 0
if (!eglChooseConfig(eglDisplay, configAttribs, , 1, )
|| (nConfig != 1)){
CHECK_EGL_ERROR("eglChooseConfig", eglStat);
}

printf("-> %d egl config returned", nConfig);
#else
if (!eglGetConfigs(eglDisplay, NULL, 0, ) || count < 1)
		assert(0);

	configs = calloc(count, sizeof *configs);
	assert(configs);

	ret = eglChooseConfig(eglDisplay, 

Re: Touch input behavior on overlapping ivi surfaces

[Vikas Patil]

On Tue, May 24, 2016 at 6:44 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Tue, 24 May 2016 18:29:52 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> Dear All,
>>
>> Here (attached here the image ) the touch input is not going to surface 1
>> even after touching any of the two buttons on surface 1.  Instead touch
>> event goes to surface 2. Also if I touch anywhere in the area marked green
>> also goes to surface 2 even it being the part of surface 1. Touching on the
>> rest of the light blue area delivers touch correctly to surface 1.
>>
>> Both the surfaces are on one layer only (e.g. layer id 1000)
>>
>> Any one here faced such issue? What could be going wrong here? Any
>> suggestions/ideas?
>>
>> Also try the limiting the input acceptance area using wayland region. But
>> it didn't work.
>>
>> input_region = wl_compositor_create_region(wlCompositor);
>>
>> wl_region_add(input_region, 728, 5, 72, 144);
>>
>> wl_surface_set_input_region(surface, input_region);
>
> Mind, you need a wl_surface_commit() before that applies. And then,
> maybe something else overwrites it immediately after your hack, sending
> another set_input_region request.
>

Do you mean I need to call the wl_surface_commit() immediately after
wl_surface_set_input_region() even if it is EGL surface and
somewhere eglSwapBuffers() gets called? If yes then I will test with it.

What is the usage of wl_surface_commit() with EGL and non EGL surfaces (shm)?

>> I am on weston 1.8, wayland-ivi-extension 1.4.0 and qt/qtwayland 5.5.1.
>
> I really have no idea, but I am quite sure it is a surface configuration
> issue outside of weston core.
>
> You could look at the Wayland protocol dump of the client to see how it
> sets the surfaces up. Input region should be clipped to the surface
> area in weston core, but maybe the surface has transparent areas and a
> misplaced input region?
>
> Does that setup even let Weston core handle input focus, or is all that
> hijacked to LayerManager or something?
>

Thanks. I will have a look at wayland dump. There are ILM API (i.e
ilm_setInputFocus) to set the input focus for specific input device
for specific surface. However AFAIK it is not required for touch input
and it is available for all the surfaces while in case of pointer and
keyboard it need to set using this API for particular surface to
receive input from it.

I really need to know what is the default input behavior with weston
core and ILM (ivi-shell and ilm control) for touch, pointer and
keyboard.

Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Touch input behavior on overlapping ivi surfaces

[Vikas Patil]

Dear All,

Here (attached here the image ) the touch input is not going to surface 1
even after touching any of the two buttons on surface 1.  Instead touch
event goes to surface 2. Also if I touch anywhere in the area marked green
also goes to surface 2 even it being the part of surface 1. Touching on the
rest of the light blue area delivers touch correctly to surface 1.

Both the surfaces are on one layer only (e.g. layer id 1000)

Any one here faced such issue? What could be going wrong here? Any
suggestions/ideas?

Also try the limiting the input acceptance area using wayland region. But
it didn't work.

input_region = wl_compositor_create_region(wlCompositor);

wl_region_add(input_region, 728, 5, 72, 144);

wl_surface_set_input_region(surface, input_region);

I am on weston 1.8, wayland-ivi-extension 1.4.0 and qt/qtwayland 5.5.1.




​Thanks & Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

How to start weston with non root user?

[Vikas Patil]

Dear All,

I have a requirement to start the weston 1.8.0 with non-root user. I
tried it starting weston using following commands in systemd unit file
with "root" user (first to verify if all commands works) .
However with this it shows service status as "dead". Later intension
is to start with some user. e.g User=display

Could you please give some pointer what might be going wrong here? How
to start weston correctly without root user? My target is based on
systemd but it is not running "systemd-logind"

ExecStartPre=/bin/mkdir -p /var/run/root/1000
ExecStartPre=/bin/chmod 0700 /var/run/root/1000
ExecStart=/usr/bin/openvt -c 1 /usr/bin/weston-launch -- --idle-time=0
--device=/dev/fb1 --backend=fbdev-backend.so --use-gal2d=0 --use-gl=1
--log=/tmp/weston.log


root@a1linux:~# systemctl status weston -l
weston.service - weston (wayland compositor)
   Loaded: loaded (/lib/systemd/system/weston.service; static)
   Active: inactive (dead) since Thu 1970-01-01 00:00:02 UTC; 45 years
9 months ago
  Process: 242 ExecStart=/usr/bin/openvt -c 1 /usr/bin/weston-launch
-u root -- --device=/dev/fb1 --backend=fbdev-backend.so --use-gal2d=0
--use-gl=1 --log=/tmp/weston.log (code=exited, status=0/SUCCESS)
  Process: 224 ExecStartPre=/bin/chmod 0700 /var/run/root/1000
(code=exited, status=0/SUCCESS)
  Process: 160 ExecStartPre=/bin/mkdir -p /var/run/root/1000
(code=exited, status=0/SUCCESS)
 Main PID: 242 (code=exited, status=0/SUCCESS)
root@a1linux:~#


However when I start weston using one of following command it works fine.

1. Inside weston.service
ExecStart=/usr/bin/weston --tty=1 --device=/dev/fb1
--backend=fbdev-backend.so --use-gal2d=0 --use-gl=1
--log=/tmp/weston.log

or

2. Manually running commands on terminal (teraterm)
#export XDG_RUNTIME_DIR=/var/run/root/1000
#openvt -c 1 /usr/bin/weston-launch -- --device=/dev/fb1
--backend=fbdev-backend.so --use-gal2d=0 --use-gl=1
--log=/tmp/weston.log
- However in this case I can see weston is running but no GUI on
display also could not locate any error in weston.log. What might be
going wrong here?

Thanks & regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland crash debugging help required

[Vikas Patil]

Hi Pekka Paalanen,

Thanks a lot for your comment.

As you mentioned this could be the case of multiple threads receiving
and dispatching events as I am using [1] qtwayland 5.5.1 and [2]
imxeglviv video sink. Both the component uses the
wl_display_prepare_read() and wl_display_read_events(). Qtwayland uses
the socke and signal while imxeglvivsink uses the poll.

How could I confirm that this is the same race mentioned in
https://bugs.freedesktop.org/show_bug.cgi?id=91273 or
https://bugs.freedesktop.org/show_bug.cgi?id=91768 ?

[1] 
http://code.qt.io/cgit/qt/qtwayland.git/commit/?h=5.5=8cc88f4854b72bb270e4b701d15ada7bdbb74ff4
[2] 
https://github.com/Freescale/gstreamer-imx/blob/master/src/eglvivsink/egl_platform_wayland.c

Yes, I won't be able to share the application source but I will try to
create test application and if I could I will share.

Thanks & Regards,
Vikash

On Wed, Mar 30, 2016 at 1:38 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Wed, 30 Mar 2016 12:01:58 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> Dear all,
>>
>> I am observing "Segmentation fault" with below mentioned back-trace
>> while playing video (loop back mode )and continuously pressing home
>> button on target (which brings video screen to home screen of HMI).
>>
>> Printing the locals shows null pointer deference (i.e. line 46, print
>> elm->next,  wl_list_insert, /wayland-1.8.1/src/wayland-util.c:46  )
>>
>> Am I hitting some known issue with wayland/weston? How should I debug
>> this further and find the root cause if it is not known issue? Could
>> you guys please provide input/suggestion on finding the root cause?
>>
>> I am on wayland/weston 1.8.0 and using i.MX6/Linux3.14.28. Test
>> application is based on gstreamer1.0 and uses wayland based
>> “imxeglvivsink“ as video sink plug-in. Home button is a gpio mapped to
>> KEY_HOME as standard keyboard and uses input stack as it is from
>> wayland/weston and libinput.
>>
>>
>> Backtrace:
>> 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.
>> Core was generated by `./testVideoPlayer'.
>> Program terminated with signal SIGSEGV, Segmentation fault.
>>
>> #0  wl_list_insert (list=0x1, elm=0x1802660, elm@entry=0x16c) at
>> /usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-util.c:46
>>
>> 46  elm->next = list->next;
>>
>> (gdb) bt
>>
>> #0  wl_list_insert (list=0x1, elm=0x1802660, elm@entry=0x16c) at
>> /usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-util.c:46
>>
>> #1  0x75c412c8 in queue_event (len=1975783972, display=0x180116c) at
>> /usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:1122
>>
>> #2  read_events (display=) at
>> /usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:1207
>>
>> #3  0x75c42030 in wl_display_dispatch_queue
>> (display=display@entry=0x76036800,  queue=queue@entry=0x760005a8) at
>> /usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:1579
>>
>> #4  0x75c42290 in wl_display_roundtrip_queue (display=0x76036800,
>> queue=0x760005a8) at
>> /usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:982
>>
>> #5  0x75d56cb4 in wl_egl_window_destroy (window=0x1801104) at
>> gc_egl_platform.c:779
>>
>> #6  0x75d7ab44 in gst_imx_egl_viv_sink_egl_platform_shutdown_window (
>> platform=0x76016f00) at ../src/eglvivsink/egl_platform_wayland.c:990
>>
>> #7  0x75d77e68 in gst_imx_egl_viv_sink_gles2_renderer_thread (
>> thread_data=) at ../src/eglvivsink/gles2_renderer.c:227
>
> Hi,
>
> this looks very much like a threading issue in gst imx egl viv sink or
> perhaps in the proprietary EGL implementation. Being random instead of
> deterministically every time you press the button also hints to a race.
>
> Note, that the code you are looking at is not Weston, it is some
> application. I don't think this has anything to do with Weston or
> Wayland really...
>
> Unless this happens to be the case of multiple threads racing between
> setting up queues and listeners for a wl_callback vs. receiving and
> dispatching events: https://bugs.freedesktop.org/show_bug.cgi?id=91768
>
> However, there are things that make looking into your issue very
> difficult for upstream:
> - old weston and wayland
> - gstreamer sink written for a proprietary software platform
> - proprietary EGL implementation
> - use of IVI
> - use of applications we cannot have the sources for (I presume)
>
> IOW, it doesn't look like there would be any way for us to reproduce
> the issue to have a look into.
>
>
> Thanks,
> pq
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

wayland crash debugging help required

[Vikas Patil]

Dear all,

I am observing "Segmentation fault" with below mentioned back-trace
while playing video (loop back mode )and continuously pressing home
button on target (which brings video screen to home screen of HMI).

Printing the locals shows null pointer deference (i.e. line 46, print
elm->next,  wl_list_insert, /wayland-1.8.1/src/wayland-util.c:46  )

Am I hitting some known issue with wayland/weston? How should I debug
this further and find the root cause if it is not known issue? Could
you guys please provide input/suggestion on finding the root cause?

I am on wayland/weston 1.8.0 and using i.MX6/Linux3.14.28. Test
application is based on gstreamer1.0 and uses wayland based
“imxeglvivsink“ as video sink plug-in. Home button is a gpio mapped to
KEY_HOME as standard keyboard and uses input stack as it is from
wayland/weston and libinput.


Backtrace:
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.
Core was generated by `./testVideoPlayer'.
Program terminated with signal SIGSEGV, Segmentation fault.

#0  wl_list_insert (list=0x1, elm=0x1802660, elm@entry=0x16c) at
/usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-util.c:46

46  elm->next = list->next;

(gdb) bt

#0  wl_list_insert (list=0x1, elm=0x1802660, elm@entry=0x16c) at
/usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-util.c:46

#1  0x75c412c8 in queue_event (len=1975783972, display=0x180116c) at
/usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:1122

#2  read_events (display=) at
/usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:1207

#3  0x75c42030 in wl_display_dispatch_queue
(display=display@entry=0x76036800,  queue=queue@entry=0x760005a8) at
/usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:1579

#4  0x75c42290 in wl_display_roundtrip_queue (display=0x76036800,
queue=0x760005a8) at
/usr/src/debug/wayland/1.8.1-r0/wayland-1.8.1/src/wayland-client.c:982

#5  0x75d56cb4 in wl_egl_window_destroy (window=0x1801104) at
gc_egl_platform.c:779

#6  0x75d7ab44 in gst_imx_egl_viv_sink_egl_platform_shutdown_window (
platform=0x76016f00) at ../src/eglvivsink/egl_platform_wayland.c:990

#7  0x75d77e68 in gst_imx_egl_viv_sink_gles2_renderer_thread (
thread_data=) at ../src/eglvivsink/gles2_renderer.c:227

#8  0x76cf265c in ?? () from /usr/lib/libglib-2.0.so.0

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) print list
$1 = (struct wl_list *) 0x1

(gdb) print elm
$2 = (struct wl_list *) 0x1802660

(gdb) print elm->next
$3 = (struct wl_list *) 0x0

(gdb)



Thanks & Regards,
Vikas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

How to build weston/wayland with debug information?

[Vikas Patil]

Dear All,

How can I build wayland/weston with debug information in it? I mean
debug build of wayland/weston. I am using weston 1.8.0 and building
using yocto based environment.

Thanks & Regards,
Vikas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: How to build weston/wayland with debug information?

[Vikas Patil Gmail]

Oh! Forgot that yocto generated debug packages as well. 

Regards,
Vikas

-Original Message-
From: "Vikas Patil" <vikasmpa...@gmail.com>
Sent: ‎12/‎23/‎2015 3:26 PM
To: "wayland mailing list" <wayland-devel@lists.freedesktop.org>
Subject: How to build weston/wayland with debug information?

Dear All,

How can I build wayland/weston with debug information in it? I mean
debug build of wayland/weston. I am using weston 1.8.0 and building
using yocto based environment.

Thanks & Regards,
Vikas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Touch events not reviving with wayland-ivi-extenssion 1.4.0 and wayland video sink

[Vikas Patil]

If I force to pass the if condition as follows using the surface id
even though surfaces doesn't match, it is working. Does this might be
due to the way I created the surface 90? Surface 90 also has
subsurface, does it anyway related to subsurface?

Alos "grab->touch->focus->surface" what this surface is and who creates it?

surfID = interface->get_id_of_surface(surf_ctx->layout_surface);

/* Touches set touch focus */

if (grab->touch->num_tp == 1) {

if (surf == grab->touch->focus->surface ||  surfID == 90) {

surf_ctx->focus |= ILM_INPUT_DEVICE_TOUCH;

send_input_focus(seat->input_ctx,


interface->get_id_of_surface(surf_ctx->layout_surface),

 ILM_INPUT_DEVICE_TOUCH, ILM_TRUE);

}


Thanks & Regards,
Vikash

On Mon, Dec 14, 2015 at 8:53 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
> I am hitting else part of below code for this issue. Any ideas?
>
> touch_grab_down() from ivi-input-controller.c
>
>  /* Touches set touch focus */
> if (grab->touch->num_tp == 1) {
> if (surf == grab->touch->focus->surface) {
> surf_ctx->focus |= ILM_INPUT_DEVICE_TOUCH;
> send_input_focus(seat->input_ctx,
>
> interface->get_id_of_surface(surf_ctx->layout_surface),
>  ILM_INPUT_DEVICE_TOUCH, ILM_TRUE);
> } else {
> surf_ctx->focus &= ~ILM_INPUT_DEVICE_TOUCH;
> <--
> send_input_focus(seat->input_ctx,
>
> interface->get_id_of_surface(surf_ctx->layout_surface),
>  ILM_INPUT_DEVICE_TOUCH, ILM_FALSE);
> }
> }
>
> /* This code below is slightly redundant, since we have already
>  * decided only one surface has touch focus */
> if (!(surf_ctx->focus & ILM_INPUT_DEVICE_TOUCH))
> continue;
> <-
>
>
> Thanks & Regards,
> Vikash
>
> On Mon, Dec 14, 2015 at 3:25 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
>> Sorry. Forgot to attach the log file. Attached here.
>>
>> Thanks & Regards,
>> Vikas
>>
>> On Mon, Dec 14, 2015 at 3:24 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
>>> Hi Eugen Friedrich
>>>
>>> Thanks a lot for your quick reply.
>>>
>>> Attached here the file with WAYLAND_DEBUG=1 log when the gstreamer
>>> plug-in is in use. I can see "ivi_input@18.input_focus(90, 4, 0)" for
>>> the surface from plug-in but no touch events.
>>>
>>> Here is the output of APIs
>>>
>>> root@linux-9939-a1:~# LayerManagerControl get input device default 
>>> capabilities
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> pointer
>>> keyboard
>>> touch
>>>
>>> root@linux-9939-a1:~# LayerManagerControl get surface 90 acceptance
>>> Interpreter error: 'acceptance' not recognized.
>>>
>>> root@orinoco-9939-a1:~# LayerManagerControl get input devices with all
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> default
>>>
>>> root@linux-9939-a1:~# LayerManagerControl get input focus
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> failed to get surface context in ilmControl
>>> surface 90:
>>> surface 63:
>>> surface 62:
>>> surface 61:
>>> surface 60: pointer keyboard
>>>
>>>
>>> Thanks & Regards,
>>> Vikas
>>>
>>> On Mon, Dec 14, 2015 at 3:01 PM, Friedrich, Eugen (ADITG/SW1)
>>> <efriedr...@de.adit-jv.com> wrote:
>>>> Hello Vikas,
>>>>
>>>> Could you please add the WAYLAND_DEBUG=1 traces from you application, to 
>>>> see if the input events are reaching the client.
>>>>
>>>> 

Re: Touch events not reviving with wayland-ivi-extenssion 1.4.0 and wayland video sink

[Vikas Patil]

Hi Eugen Friedrich

Thanks a lot for your quick reply.

Attached here the file with WAYLAND_DEBUG=1 log when the gstreamer
plug-in is in use. I can see "ivi_input@18.input_focus(90, 4, 0)" for
the surface from plug-in but no touch events.

Here is the output of APIs

root@linux-9939-a1:~# LayerManagerControl get input device default capabilities
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
pointer
keyboard
touch

root@linux-9939-a1:~# LayerManagerControl get surface 90 acceptance
Interpreter error: 'acceptance' not recognized.

root@orinoco-9939-a1:~# LayerManagerControl get input devices with all
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
default

root@linux-9939-a1:~# LayerManagerControl get input focus
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
failed to get surface context in ilmControl
surface 90:
surface 63:
surface 62:
surface 61:
surface 60: pointer keyboard


Thanks & Regards,
Vikas

On Mon, Dec 14, 2015 at 3:01 PM, Friedrich, Eugen (ADITG/SW1)
<efriedr...@de.adit-jv.com> wrote:
> Hello Vikas,
>
> Could you please add the WAYLAND_DEBUG=1 traces from you application, to see 
> if the input events are reaching the client.
>
> Also the output of the following API would be helpful:
> ilm_getInputFocus,
> ilm_getInputDevices,
> ilm_getInputAcceptanceOn(with you surface id)
>
> the API's will return a list of devices or surfaces, please print the 
> complete list.
>
>
> Best regards
>
> Eugen Friedrich
> Software Group I (ADITG/SW1)
>
> Tel. +49 5121 49 6921
>
>> -Original Message-
>> From: genivi-ivi-layer-management-boun...@lists.genivi.org [mailto:genivi-
>> ivi-layer-management-boun...@lists.genivi.org] On Behalf Of Vikas Patil
>> Sent: Samstag, 12. Dezember 2015 12:57
>> To: genivi-ivi-layer-managem...@lists.genivi.org; meta-
>> freesc...@yoctoproject.org; Tanibata, Nobuhiko (ADITJ/SWG); Carlos Rafael
>> Giani; wayland mailing list
>> Subject: Touch events not reviving with wayland-ivi-extenssion 1.4.0 and
>> wayland video sink
>>
>> Dear All,
>>
>> I am using wayland video sink (i.e. imxeglvivsink) from gstreamer1.0-plugins-
>> imx [1] to play the video along with weston 1.8.0 and wayland-ivi-extenstion
>> 1.4.0. I have modified “imxeglvivsink” to have the ilm and touch input
>> support [2]. Basically I am posting touch events on GST bus and application
>> want to have the touch can read the messages and process the touch. This is
>> working fine if I don’t load the “ivi-input-controller.so”. If I load the 
>> “ivi-input-
>> controller.so”
>> I am not able to get the touch event inside this plug-in. I have tried 
>> setting
>> touch input focus to the surface from this wayland video plug-in using
>> “LayermanagerControl” and ilm_setInputFocus” [3] but no luck.
>>
>>
>> Also touch works fine even if I load “ivi-input-controller.so” with other
>> applications. So I suspect some modification are required to ”imxeglvivsink”
>> [2] or “wayland-ivi-extension/weston”.
>>
>> Do you know what might be going wrong? Could anyone here give some
>> suggestions/ideas to tryout and fix this?
>>
>> Also “LayerManagerControl get surface 90 acceptance” doesn’t seem to
>> work for me. Any inputs for this?
>>
>> I have tried modifying “gst_imx_egl_viv_sink_egl_platform_mainloop”
>> function in various ways but no luck and I think implementation is correct 
>> (as
>> it works well without ivi-input-controller)
>>
>> Following is the platform setup and weston configuration.
>>
>> i.MX6 Duallite
>> Linux 3.14.28
>> Weston 1.8.0 with (ivi-shell.so with fbdev backend and gal2d renderer)
>> Wayland-ivi-extension 1.4.0 (using ivi-controller.so, ivi-input-controller.so
>> gstreamer-imx plugin QTwayland 5.4.2/Qt 5.4.2
>>
>> Weston.ini contains:
>>
>> [core]
>> shell=ivi-shell.so
>>
>> [ivi-shell]
>> ivi-module=ivi-controller.so,ivi-input-controller.so
>> ivi-shell-user-interface=/usr/lib/weston/weston-ivi-shell-user-interface
>>
>>
>> [1] https://github.com/Freescale/gstreamer-imx/tree/master/src/eglvivsink
>> [2]See attached modified file “egl_platform_wayland.c” from imxeglvivsink
>> [3]
>> http://wiki.projects.genivi.org/index.php/Getting_Started_with_new_Input
>> _Handling_APIs
>>
>>
>>
>> Thanks & Regards,
>> Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Touch events not reviving with wayland-ivi-extenssion 1.4.0 and wayland video sink

[Vikas Patil]

Dear All,

I am using wayland video sink (i.e. imxeglvivsink) from
gstreamer1.0-plugins-imx [1] to play the video along with weston 1.8.0
and wayland-ivi-extenstion 1.4.0. I have modified “imxeglvivsink” to
have the ilm and touch input support [2]. Basically I am posting touch
events on GST bus and application want to have the touch can read the
messages and process the touch. This is working fine if I don’t load
the “ivi-input-controller.so”. If I load the “ivi-input-controller.so”
I am not able to get the touch event inside this plug-in. I have tried
setting touch input focus to the surface from this wayland video
plug-in using “LayermanagerControl” and ilm_setInputFocus” [3] but no
luck.


Also touch works fine even if I load “ivi-input-controller.so” with
other applications. So I suspect some modification are required to
”imxeglvivsink” [2] or “wayland-ivi-extension/weston”.

Do you know what might be going wrong? Could anyone here give some
suggestions/ideas to tryout and fix this?

Also “LayerManagerControl get surface 90 acceptance” doesn’t seem to
work for me. Any inputs for this?

I have tried modifying “gst_imx_egl_viv_sink_egl_platform_mainloop”
function in various ways but no luck and I think implementation is
correct (as it works well without ivi-input-controller)

Following is the platform setup and weston configuration.

i.MX6 Duallite
Linux 3.14.28
Weston 1.8.0 with (ivi-shell.so with fbdev backend and gal2d renderer)
Wayland-ivi-extension 1.4.0 (using ivi-controller.so, ivi-input-controller.so
gstreamer-imx plugin
QTwayland 5.4.2/Qt 5.4.2

Weston.ini contains:

[core]
shell=ivi-shell.so

[ivi-shell]
ivi-module=ivi-controller.so,ivi-input-controller.so
ivi-shell-user-interface=/usr/lib/weston/weston-ivi-shell-user-interface


[1] https://github.com/Freescale/gstreamer-imx/tree/master/src/eglvivsink
[2]See attached modified file “egl_platform_wayland.c” from imxeglvivsink
[3] 
http://wiki.projects.genivi.org/index.php/Getting_Started_with_new_Input_Handling_APIs



Thanks & Regards,
Vikash
#include 
#include 
#include 
#include 
#include 

#include 

#include "egl_platform.h"
#include "egl_misc.h"
#include "gl_headers.h"

#define ILM_SUPPORT 1



#ifdef ILM_SUPPORT
#include "ilm/ilm_control.h"
#include "ilm/ilm_client.h"
#include "ilm/ilm_input.h"

//int   width = 800;
//int   height = 480;
t_ilm_layer   ilmLayerId = 1000;
t_ilm_surface ilmSurfaceId = 90;
#endif 


GST_DEBUG_CATEGORY_STATIC(imx_egl_platform_wl_debug);
#define GST_CAT_DEFAULT imx_egl_platform_wl_debug


struct _GstImxEglVivSinkEGLPlatform
{
	EGLNativeDisplayType native_display;
	EGLNativeWindowType native_main_window;
	EGLNativeWindowType native_window;
	EGLDisplay egl_display;
	EGLContext egl_context;
	EGLSurface egl_main_surface;
	EGLSurface egl_surface;
	
	GstElement* sink;
	
	GstImxEglVivSinkWindowResizedEventCallback window_resized_event_cb;
	GstImxEglVivSinkWindowRenderFrameCallback render_frame_cb;

	gpointer user_context;

	gboolean fullscreen;
	guint video_par_n, video_par_d;
	guint fixed_window_width, fixed_window_height, video_width, video_height;
	guint current_width, current_height;
	guint screen_width, screen_height;
	gint pending_x_coord, pending_y_coord;
	gint x_coord, y_coord;
	gboolean pending_subsurface_desync;

	GMutex mutex;

	struct wl_display *display;
	struct wl_registry *registry;
	int display_fd;
	struct wl_compositor *compositor;
	struct wl_subcompositor *subcompositor;
#ifndef ILM_SUPPORT
	struct wl_shell *shell;
#endif
	struct wl_output *output;

	struct wl_surface *main_surface;
	struct wl_surface *surface;
	struct wl_subsurface *subsurface;
#ifndef ILM_SUPPORT
	struct wl_shell_surface *shell_surface;
#endif


	struct wl_seat *seat;
	struct wl_touch *wl_touch;


	struct wl_callback *frame_cb;
	gboolean frame_callback_invoked;

	int ctrl_pipe[2];

	gboolean configured, do_render;
};

typedef enum
{
	TOUCH_HANDLE_DOWN,
	TOUCH_HANDLE_UP,
	TOUCH_HANDLE_MOTION,
	TOUCH_HANDLE_FRAME,
	TOUCH_HANDLE_CANCEL
};

#define EGL_PLATFORM_LOCK(platform) g_mutex_lock(&((platform)->mutex))
#define EGL_PLATFORM_UNLOCK(platform) g_mutex_unlock(&((platform)->mutex))


typedef enum
{
	GSTIMX_EGLWL_CMD_REDRAW,
	GSTIMX_EGLWL_CMD_CALL_RESIZE_CB,
	GSTIMX_EGLWL_CMD_STOP_MAINLOOP
}
GstImxEGLWLCmds;




static void log_handler(const char *format, va_list args)
{
	gst_debug_log_valist(imx_egl_platform_wl_debug, GST_LEVEL_LOG, __FILE__, __func__, __LINE__, NULL, format, args);
}


static void static_global_init(void)
{
	static gboolean initialized = FALSE;
	if (!initialized)
	{
		GST_DEBUG_CATEGORY_INIT(imx_egl_platform_wl_debug, "imxeglplatform_wl", 0, "imxeglvivsink Wayland platform");

		wl_log_set_handler_client(log_handler);

		initialized = TRUE;
	}
}




static void calculate_adjusted_window_size(GstImxEglVivSinkEGLPlatform *platform, guint *actual_width, guint *actual_height)
{
	gboolean b;
	guint window_par_n, window_par_d, display_ratio_n, display_ratio_d;

	window_par_n = 4;
	window_par_d = 3;

	b = 

Re: Touch event delayed or missing with weston 1.8.0 and qtwayland 5.4.2

[Vikas Patil]

Hi Giulio,

Thanks for the suggestion. I was able to capture the wayland log from
weston and HMI as per your suggestion with good and bad scenarios. You
will see two times wayland log, I think this is due to I have
specified WAYLAND_DEBUG=1 for weston and hmi both.

Captured log for below five scenarios. 1st scenario is good and rest
is bad.. Attached here the logs for each scenario. If possible could
you point me out or suggest what might be going wrong?

Scenario 1: When the button is pressed, it is displayed as pressed,
when released, the view is updated without delay.
- This I think is good case and these call sequence should be there
each time and can be used as reference.
- Also looking at the timestamp it takes 110 ms from first touch_down
event to last callback_done notify. Which seems reasonable.

Scenario 2: When the button is pressed, it is displayed as pressed,
when released, the view is updated after some delay.
- Here all call sequence seems ok to me after referring touch id,
surface id and buffer id but can't make out any wrong calls.
- Also looking at the timestamp it takes 783 ms from first touch_down
event to last callback_done notify. Any idead what can cause this?

Scenario 3: When the button is pressed, it is not displayed as
pressed, observed delay in wayland log from weston and hmi
- Here no surface events, request observed and all touch events
immediately (down, frame and up). Any idea what can cause this?

Scenario 4: When the button is pressed, it is not displayed as
pressed, observed immediate all touch events log from weston and hmi
- here I think error is touch_down, touch_frame and touch_up comes
immediate without attach, damage, commit before touch_up.

Scenario 5: When the button is pressed, it is not displayed as
pressed, observed delay in wayland log from weston and hmi, second
touch to recover

@All, Waiting for comments/suggestions/inputs and thanking you all.

Thanks & Regards,
Vikas

On Sat, Nov 21, 2015 at 1:28 AM, Giulio Camuffo <giuliocamu...@gmail.com> wrote:
> 2015-11-20 13:28 GMT+02:00 Vikas Patil <vikasmpa...@gmail.com>:
>> I think when I feel delay in touch. Seeing following log from weston
>> (I added the prints) and evtest prints. I am testing this with button
>> on HMI. When the button is pressed, it is displayed as pressed, but
>> when released, the view is not updated immediately and it is still
>> displayed as pressed for sometime and after very little delay it shows
>> released.
>>
>> Could anyone give some inputs?
>
> You should export the environment variable WAYLAND_DEBUG=1 on the
> client side and check if the wl_touch events are coming correctly at
> the right time. If they are the bug is probably in the client,
> otherwise it's in the compositor.
>
>
> --
> Giulio
>
>>
>>
>> weston log:
>>
>> [13:13:40.144] -> notify_touch: WL_TOUCH_DOWN
>> [13:13:40.144] -> notify_touch: touch_grab_down
>> [13:13:40.144] -> notify_touch_frame
>> [13:13:40.144] -> notify_touch: touch_grab_frame
>> [13:13:40.198] -> notify_touch: WL_TOUCH_MOTION
>> [13:13:40.198] -> notify_touch: touch_grab_motion
>> [13:13:40.198] -> notify_touch_frame
>> [13:13:40.198] -> notify_touch: touch_grab_frame
>> [13:13:40.208] -> notify_touch: WL_TOUCH_MOTION
>> [13:13:40.208] -> notify_touch: touch_grab_motion
>> [13:13:40.208] -> notify_touch_frame
>> [13:13:40.208] -> notify_touch: touch_grab_frame
>> [13:13:40.262] -> notify_touch: WL_TOUCH_MOTION
>> [13:13:40.262] -> notify_touch: touch_grab_motion
>> [13:13:40.262] -> notify_touch_frame
>> [13:13:40.262] -> notify_touch: touch_grab_frame
>> [13:13:40.342] -> notify_touch: WL_TOUCH_UP
>> [13:13:40.342] -> notify_touch: touch_grab_up
>> [13:13:40.342] -> notify_touch_frame
>> [13:13:40.342] -> notify_touch: touch_grab_frame
>>
>> evtest log:
>>
>> Event: time 1444828420.143687, type 3 (EV_ABS), code 57
>> (ABS_MT_TRACKING_ID), value 82
>> Event: time 1444828420.143687, type 3 (EV_ABS), code 53
>> (ABS_MT_POSITION_X), value 78
>> Event: time 1444828420.143687, type 3 (EV_ABS), code 54
>> (ABS_MT_POSITION_Y), value 431
>> Event: time 1444828420.143687, type 3 (EV_ABS), code 58
>> (ABS_MT_PRESSURE), value 35
>> Event: time 1444828420.143687, -- EV_SYN 
>> Event: time 1444828420.198068, type 3 (EV_ABS), code 53
>> (ABS_MT_POSITION_X), value 74
>> Event: time 1444828420.198068, -- EV_SYN 
>> Event: time 1444828420.207220, type 3 (EV_ABS), code 53
>> (ABS_MT_POSITION_X), value 73
>> Event: time 1444828420.

Re: How to hide mouse cursor with weston and ivi-shell?

[Vikas Patil]

On Wed, Dec 9, 2015 at 6:29 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Wed, 9 Dec 2015 18:18:04 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> Dear All,
>>
>> I would like to have the mouse pointer support available with weston
>> and ivi-shell (with ivi-controller.so) but want to hide the cursor
>> which is always visible.
>>
>> Is there any easy way I can do this? Any ideas/suggestions?
>
> Hi,
>
> what is your use case? There are several answers depending on what you
> are doing and what kind of applications you are running.

Thanks for your quick reply.

I need mouse pointer support as rotary knob hard key on our platform
on GPIO added as standard mouse wheel support. I also required mouse
pointer support for the platform configuration which doesn't has touch
support so mouse can be used for development. If I know how to just
hide the cursor, probably I will try to do it via weston.ini config so
when required visibility of cursor can be enabled/disabled.

I  have application Qt/Qtwayland based HMI on top of weston and ivi-shell.

> All cursors are always set by clients, either applications or in
> hmi-controller's case weston-ivi-shell-user-interface.

I am not making use of hmi-controller and hence
weston-ivi-shell-user-interface. I am using ilm apis directly with
ivi-controller.so.

>> ** I can hide if I disable the MOUSE capability via udev custom rule
>> but I don't want to remove the pointer support as it is required. Just
>> want to hide the pointer drawing.
>
> How does pointer support without a cursor make any sense?
> You would be poking blind with the mouse, so there is no ready-made
> option to do that.

Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

How to hide mouse cursor with weston and ivi-shell?

[Vikas Patil]

Dear All,

I would like to have the mouse pointer support available with weston
and ivi-shell (with ivi-controller.so) but want to hide the cursor
which is always visible.

Is there any easy way I can do this? Any ideas/suggestions?

** My weston.ini file for reference.Removing "cursor-theme" and
"cursor-size" doesn't help as it is used by hmi-controller adn I am
not using it.

[core]
shell=ivi-shell.so

[ivi-shell]
ivi-module=ivi-controller.so

cursor-theme=default
cursor-size=32

** I can hide if I disable the MOUSE capability via udev custom rule
but I don't want to remove the pointer support as it is required. Just
want to hide the pointer drawing.

If I remove "ENV{ID_INPUT_MOUSE}="1"" from following line cursor is no
longer visible.

SUBSYSTEM=="input", ENV{ID_INPUT}="1", ENV{ID_INPUT_TOUCHSCREEN}="1",
ENV{ID_INPUT_MOUSE}="1", ENV{ID_INPUT_KEYBOARD}="1"



Thanks & Regards,
Vikas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How to hide mouse cursor with weston and ivi-shell?

[Vikas Patil]

On Wed, Dec 9, 2015 at 7:45 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Wed, 9 Dec 2015 18:50:38 +0530
> Vikas Patil <vikasmpa...@gmail.com> wrote:
>
>> On Wed, Dec 9, 2015 at 6:29 PM, Pekka Paalanen <ppaala...@gmail.com> wrote:
>> > On Wed, 9 Dec 2015 18:18:04 +0530
>> > Vikas Patil <vikasmpa...@gmail.com> wrote:
>> >
>> >> Dear All,
>> >>
>> >> I would like to have the mouse pointer support available with weston
>> >> and ivi-shell (with ivi-controller.so) but want to hide the cursor
>> >> which is always visible.
>> >>
>> >> Is there any easy way I can do this? Any ideas/suggestions?
>> >
>> > Hi,
>> >
>> > what is your use case? There are several answers depending on what you
>> > are doing and what kind of applications you are running.
>>
>> Thanks for your quick reply.
>>
>> I need mouse pointer support as rotary knob hard key on our platform
>> on GPIO added as standard mouse wheel support. I also required mouse
>
> Hi,
>
> I'll defer to Peter whether that device should be a pointer device or
> something completely different. I would guess something different...
>
> How do you decide which client or surface should receive the rotary
> knob events?
>

To avoid any changes in input stack, we intend to use the standard
pointer support available with rotatry knob exposing event from it as
REL_WHEEL. GENIVI wayland-ivi-extension has input apis to set the
focus to specific surface with specific input device. (see:
http://wiki.projects.genivi.org/index.php/Getting_Started_with_new_Input_Handling_APIs
)

>> pointer support for the platform configuration which doesn't has touch
>> support so mouse can be used for development. If I know how to just
>> hide the cursor, probably I will try to do it via weston.ini config so
>> when required visibility of cursor can be enabled/disabled.
>
> Weston automatically creates and destroys the pointer capability and
> the cursor with it whether there is a pointer device connected or not.
>
> Forcing the cursor to not show would require hacking Weston core. I
> can't help but think that this would be a poor bandaid for the
> underlying problem.
>

As we are using qtwayland, I found a way to disable it. I tried
disabling it using the environment variable with QT and it is working.
Attached here the patch for reference.

>> I  have application Qt/Qtwayland based HMI on top of weston and ivi-shell.
>>
>> > All cursors are always set by clients, either applications or in
>> > hmi-controller's case weston-ivi-shell-user-interface.
>>
>> I am not making use of hmi-controller and hence
>> weston-ivi-shell-user-interface. I am using ilm apis directly with
>> ivi-controller.so.
>
> That does not change the fact, that the client whose surface the
> pointer is on, is responsible for setting (or hiding) the cursor, when
> a pointer device exists. wl_pointer.set_cursor is part of Wayland core
> protocol and is implemented in Weston core. There are no configuration
> options or API to keep the cursor hidden unless you remove the whole
> pointer device...
>
> Hm, I suppose you could try restacking the cursor_layer behind
> everything else. That would be possible to do in ivi-shell, but I still
> don't think it would be upstreamable.
>
>> >> ** I can hide if I disable the MOUSE capability via udev custom rule
>> >> but I don't want to remove the pointer support as it is required. Just
>> >> want to hide the pointer drawing.
>> >
>> > How does pointer support without a cursor make any sense?
>> > You would be poking blind with the mouse, so there is no ready-made
>> > option to do that.
>
> It turns out your pointer device is not a pointer device and that
> causes problems. I'm not surprised.
>
>
> Thanks,
> pq
diff -Naur git_old/src/client/qwaylandinputdevice.cpp git/src/client/qwaylandinputdevice.cpp
--- git_old/src/client/qwaylandinputdevice.cpp	2015-12-10 06:14:08.0 +
+++ git/src/client/qwaylandinputdevice.cpp	2015-12-10 06:17:57.0 +
@@ -381,10 +381,12 @@
 
 void QWaylandInputDevice::setCursor(struct wl_buffer *buffer, struct wl_cursor_image *image)
 {
+static bool hide_cursor = qgetenv("QT_WAYLAND_HIDE_CURSOR").toInt();
+
 if (mCaps & WL_SEAT_CAPABILITY_POINTER) {
 mPointer->mCursorSerial = mPointer->mEnterSerial;
 /* Hide cursor */
-if (!buffer)
+if (!buffer || hide_cursor)
 {
 mPointer->set_cursor(mPointer->mEnterSerial, NULL, 0, 0);
 return;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Touch event delayed or missing with weston 1.8.0 and qtwayland 5.4.2

[Vikas Patil]

I think when I feel delay in touch. Seeing following log from weston
(I added the prints) and evtest prints. I am testing this with button
on HMI. When the button is pressed, it is displayed as pressed, but
when released, the view is not updated immediately and it is still
displayed as pressed for sometime and after very little delay it shows
released.

Could anyone give some inputs?


weston log:

[13:13:40.144] -> notify_touch: WL_TOUCH_DOWN
[13:13:40.144] -> notify_touch: touch_grab_down
[13:13:40.144] -> notify_touch_frame
[13:13:40.144] -> notify_touch: touch_grab_frame
[13:13:40.198] -> notify_touch: WL_TOUCH_MOTION
[13:13:40.198] -> notify_touch: touch_grab_motion
[13:13:40.198] -> notify_touch_frame
[13:13:40.198] -> notify_touch: touch_grab_frame
[13:13:40.208] -> notify_touch: WL_TOUCH_MOTION
[13:13:40.208] -> notify_touch: touch_grab_motion
[13:13:40.208] -> notify_touch_frame
[13:13:40.208] -> notify_touch: touch_grab_frame
[13:13:40.262] -> notify_touch: WL_TOUCH_MOTION
[13:13:40.262] -> notify_touch: touch_grab_motion
[13:13:40.262] -> notify_touch_frame
[13:13:40.262] -> notify_touch: touch_grab_frame
[13:13:40.342] -> notify_touch: WL_TOUCH_UP
[13:13:40.342] -> notify_touch: touch_grab_up
[13:13:40.342] -> notify_touch_frame
[13:13:40.342] -> notify_touch: touch_grab_frame

evtest log:

Event: time 1444828420.143687, type 3 (EV_ABS), code 57
(ABS_MT_TRACKING_ID), value 82
Event: time 1444828420.143687, type 3 (EV_ABS), code 53
(ABS_MT_POSITION_X), value 78
Event: time 1444828420.143687, type 3 (EV_ABS), code 54
(ABS_MT_POSITION_Y), value 431
Event: time 1444828420.143687, type 3 (EV_ABS), code 58
(ABS_MT_PRESSURE), value 35
Event: time 1444828420.143687, -- EV_SYN 
Event: time 1444828420.198068, type 3 (EV_ABS), code 53
(ABS_MT_POSITION_X), value 74
Event: time 1444828420.198068, -- EV_SYN 
Event: time 1444828420.207220, type 3 (EV_ABS), code 53
(ABS_MT_POSITION_X), value 73
Event: time 1444828420.207220, type 3 (EV_ABS), code 54
(ABS_MT_POSITION_Y), value 429
Event: time 1444828420.207220, -- EV_SYN 
Event: time 1444828420.261657, type 3 (EV_ABS), code 53
(ABS_MT_POSITION_X), value 72
Event: time 1444828420.261657, type 3 (EV_ABS), code 58
(ABS_MT_PRESSURE), value 70
Event: time 1444828420.261657, type 3 (EV_ABS), code 48
(ABS_MT_TOUCH_MAJOR), value 4
Event: time 1444828420.261657, -- EV_SYN 
Event: time 1444828420.341950, type 3 (EV_ABS), code 57
(ABS_MT_TRACKING_ID), value -1
Event: time 1444828420.341950, -- EV_SYN ----

Best Regards,
Vikash

On Thu, Nov 19, 2015 at 8:59 PM, Vikas Patil <vikasmpa...@gmail.com> wrote:
> Dear Community,
>
> I am using following components and seeing sometime touch doesn't
> respond (seems touch_up event delayed or some touch event missing).
> For example back button on screen takes time to go back to desired
> screen or I need to touch it again.
>
> linux 3.14.28
> weston 1.8.0 with ivi-shell
> qt 5.4.2.
> qtwayland 5.4.2 + patch to support touch
>
> I have checked with following two commands and it seems touch events
> are proper from kernel and libinput.
>
> #libinput-debug-events --device /dev/input/event0
> #evtest /dev/input/event0
>
> I am trying to understand what is happening but no luck yet. Has
> anyone observed the same and fixed it? Could you give some
> inputs/suggestions to understand and debug this?
>
> Thanking you for reading this.
>
> Thanks & Regards,
> Vikas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Touch event delayed or missing with weston 1.8.0 and qtwayland 5.4.2

[Vikas Patil]

Dear Community,

I am using following components and seeing sometime touch doesn't
respond (seems touch_up event delayed or some touch event missing).
For example back button on screen takes time to go back to desired
screen or I need to touch it again.

linux 3.14.28
weston 1.8.0 with ivi-shell
qt 5.4.2.
qtwayland 5.4.2 + patch to support touch

I have checked with following two commands and it seems touch events
are proper from kernel and libinput.

#libinput-debug-events --device /dev/input/event0
#evtest /dev/input/event0

I am trying to understand what is happening but no luck yet. Has
anyone observed the same and fixed it? Could you give some
inputs/suggestions to understand and debug this?

Thanking you for reading this.

Thanks & Regards,
Vikas
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Input: Hard-keys input support using libinput and weston 1.8.0

[Vikas Patil]

On Mon, Nov 2, 2015 at 7:56 AM, Peter Hutterer <peter.hutte...@who-t.net> wrote:
>
> On Fri, Oct 30, 2015 at 11:43:34AM +0530, Vikas Patil wrote:
> > I have a requirement where Hard-Keys input events (e.g. Home button, Back
> > button, Volume buttons or Volume Rotary Knobs) needs to be injected into
> > weston compositor and passed to application or application can listen on
> > those events using wayland/weston some way.
>hardkey button
> probably best to explain the use-case you have in a bit more detail, there
> may be more than one solution (or zero, come to think of it :)
>

I like to provide a wayland/weston APIs to application developer to
handle hardkey button events (something similar wl_touch, wl_keyboard
usage, in my case it can be wl_hardkey may be). I have five hard-keys
on IVI device connected via GPIO (button 1, button 2, power button,
rotatry knob (connected to two gpio)). These keys usage it not clear
to me at the moment but any application can use I think. Will give
more information once I get.

Is there any other method available without providing standard wayland
API to application developer to detect hard key evevnt and act on it?

One possible way to implement this is to inject hardkey event as
keyboard event to "evdev but not sure what all changes are required in
complete input stack? I think need to start with evdev modification to
throw the events with require data.


> > Does weston 1.8.0 and libinput supports such kind of inputs? Or Do I need
> > to extend the full path of input (evdev -> libinput -> weston) to support
> > this? How much effort require for this?Thanks
> >
> > Could you give some suggestions/ideas to start this as I am very new to
> > input handling? It would be also helpful if you could refer me some
> > docs/links to understand this?
>
> libinput forwards key events from evdev devices pretty much as-is, weston
> handles it depending on the keyboard layout. so one solution is to create a
> uinput device that generates those events and let the rest of the stack do
> the thing it does anyway. That requires root privs to create the uinput
> device though.
>

Thanks for the suggestion. Will look into uinput. Does this means
application then would be able to handle the hardkey as mapped key
(e.g. button 1 mapped tp A) events inside app?

> http://wayland.freedesktop.org/libinput/doc/latest/ has a simple
> architecture diagram.
> you can't inject events into libinput directly, and afaik there is no
> waylan protocol extension to allow you to this there either.
>


Best Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Input: Hard-keys input support using libinput and weston 1.8.0

[Vikas Patil]

Dear All,

I have a requirement where Hard-Keys input events (e.g. Home button, Back
button, Volume buttons or Volume Rotary Knobs) needs to be injected into
weston compositor and passed to application or application can listen on
those events using wayland/weston some way.

Does weston 1.8.0 and libinput supports such kind of inputs? Or Do I need
to extend the full path of input (evdev -> libinput -> weston) to support
this? How much effort require for this?Thanks

Could you give some suggestions/ideas to start this as I am very new to
input handling? It would be also helpful if you could refer me some
docs/links to understand this?

Thanking you.

Best Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Is VT sharing possbile with weston 1.8.0 with fbdev backend?

[Vikas Patil]

Dear All,

Does anyone know here if weston switches between VTs (Virtual Terminal)
while starting weston using "fbdev" backend and GLA2D (Freescale specific
renderer)? If yes then is there any way
to stop switching between VTs and still star it successfully?

I am using weston 1.8.0 on iMX platform with linux 3.14.28 (framebuffer
console with logo, Virtual Terminal enabled).

I used to do this with X11 using option called "sharedvt" (-sharevts: share
VTs with another X server) to avoid the flicker/screen clear displayed due
to without using this option.

Regards,
Vikash
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Is VT sharing possbile with weston 1.8.0 with fbdev backend?

[Vikas Patil Gmail]

Hi Daniel,

Thanks for your comment and suggestions. I will surely ask to freesacle 
regarding it.

I was thinking VTs sharing don't have dependencies on GAL2D. Is possible could 
you point me the hack you mentioned so I can give try?

Is VT sharing possible if I use GLES renderer with fbdev backend?

I am trying splash screen and want to avoid flicker/screen clear. Using fb0 for 
splash and fb1 for Weston.

Thanks & Regards,
Vikash

-Original Message-
From: "Daniel Stone" <dan...@fooishbar.org>
Sent: ‎10/‎27/‎2015 7:43 PM
To: "Vikas Patil" <vikasmpa...@gmail.com>
Cc: "wayland mailing list" <wayland-devel@lists.freedesktop.org>
Subject: Re: Is VT sharing possbile with weston 1.8.0 with fbdev backend?

Hi,

On 27 October 2015 at 13:12, Vikas Patil <vikasmpa...@gmail.com> wrote:
> Does anyone know here if weston switches between VTs (Virtual Terminal)
> while starting weston using "fbdev" backend and GLA2D (Freescale specific
> renderer)? If yes then is there any way
> to stop switching between VTs and still star it successfully?
>
> I am using weston 1.8.0 on iMX platform with linux 3.14.28 (framebuffer
> console with logo, Virtual Terminal enabled).
>
> I used to do this with X11 using option called "sharedvt" (-sharevts: share
> VTs with another X server) to avoid the flicker/screen clear displayed due
> to without using this option.

The GAL2D backend is maintained completely separately by Freescale,
and has never been sent upstream. Unfortunately due to this (the hacks
in the code make it impossible to merge in its current form), we
cannot support the patches you have. Please get in touch with
Freescale and request support from them.

Alternately, there is support developing in Mesa for using the etnaviv
(Vivante 3D GPU) and imx-drm (Freescale 2D-ACE engine) open-source
drivers on i.MX6. If you are not able to get help from Vivante, this
could be a good option to pursue, as it has far better support.

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

RE: Is VT sharing possbile with weston 1.8.0 with fbdev backend?

[Vikas Patil Gmail]

Thanks for your comment. As I mentioned , I am working on splash screen using 
fb0 (splash image via Linux logo) and fb1 (Weston) and want to display splash 
till Weston screen comes up and then switch to fb1 using global alpha and want 
to avoid the flicker and screen clear i am seeing while Weston starts. 

Thanks,
Vikash

-Original Message-
From: "Jasper St. Pierre" <jstpie...@mecheye.net>
Sent: ‎10/‎27/‎2015 9:14 PM
To: "Vikas Patil Gmail" <vikasmpa...@gmail.com>; "Daniel Stone" 
<dan...@fooishbar.org>
Cc: "wayland mailing list" <wayland-devel@lists.freedesktop.org>
Subject: Re: Is VT sharing possbile with weston 1.8.0 with fbdev backend?

Out of curiosity, why do you require that we don't switch VTs in Weston?


On Tue, Oct 27, 2015, 8:23 AM Vikas Patil Gmail <vikasmpa...@gmail.com> wrote:

Hi Daniel,

Thanks for your comment and suggestions. I will surely ask to freesacle 
regarding it.

I was thinking VTs sharing don't have dependencies on GAL2D. Is possible could 
you point me the hack you mentioned so I can give try?

Is VT sharing possible if I use GLES renderer with fbdev backend?

I am trying splash screen and want to avoid flicker/screen clear. Using fb0 for 
splash and fb1 for Weston.

Thanks & Regards,
Vikash


From: Daniel Stone
Sent: ‎10/‎27/‎2015 7:43 PM
To: Vikas Patil
Cc: wayland mailing list
Subject: Re: Is VT sharing possbile with weston 1.8.0 with fbdev backend?


Hi,

On 27 October 2015 at 13:12, Vikas Patil <vikasmpa...@gmail.com> wrote:
> Does anyone know here if weston switches between VTs (Virtual Terminal)
> while starting weston using "fbdev" backend and GLA2D (Freescale specific
> renderer)? If yes then is there any way
> to stop switching between VTs and still star it successfully?
>
> I am using weston 1.8.0 on iMX platform with linux 3.14.28 (framebuffer
> console with logo, Virtual Terminal enabled).
>
> I used to do this with X11 using option called "sharedvt" (-sharevts: share
> VTs with another X server) to avoid the flicker/screen clear displayed due
> to without using this option.

The GAL2D backend is maintained completely separately by Freescale,
and has never been sent upstream. Unfortunately due to this (the hacks
in the code make it impossible to merge in its current form), we
cannot support the patches you have. Please get in touch with
Freescale and request support from them.

Alternately, there is support developing in Mesa for using the etnaviv
(Vivante 3D GPU) and imx-drm (Freescale 2D-ACE engine) open-source
drivers on i.MX6. If you are not able to get help from Vivante, this
could be a good option to pursue, as it has far better support.

Cheers,
Daniel

___
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: Weston 1.8.0: touch input using evdev not working

[Vikas Patil]

Creating rule with following line and then running the following two
commands made touch working.

SUBSYSTEM=="input", ENV{ID_INPUT}="1", ENV{ID_INPUT_TOUCHSCREEN}="1"

/lib/systemd/systemd-udevd --daemon
udevadm test /devices/virtual/input/input0/event0
udevadm info /dev/input/event0

Thanks for your help.

Regards,
Vikash

On Tue, Sep 29, 2015 at 10:24 AM, Vikas Patil <vikasmpa...@gmail.com> wrote:

> Hi Andreas,
>
> Thanks for inputs. Below is the requested information. I will check if I
> can upgrade systemd from 208 to 221.
>
> Do the system need to have udevd --daemon running ? I think my system uses
> mdev.
>
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/properties
> 2
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/
> abs  ev   ff   key  led  msc  rel  snd  sw
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/key
> 400 0 0 0 0 0 0 0 0 0 0
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/abs
> 6618000 3
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/ev
> b
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/ff
> 0
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/led
> 0
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/msc
> 0
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/snd
> 0
> root@linux:~# cat
> /sys/devices/virtual/input/input0/event0/device/capabilities/sw
> 0
>
> Thanks & Regards,
> Vikash
>
> On Tue, Sep 29, 2015 at 12:02 AM, Andreas Pokorny <
> andreas.poko...@canonical.com> wrote:
>
>> Hi,
>> Could you send the contents of the files
>> /sys/devices/virtual/input/input0/event0/{capabilities/*,properties}? Those
>> show the information interpreted by the builtin rules in udevadm. But
>> Benjamin might be right, upgrading to systemd-221 might fix your problem
>> already.
>>
>> regards
>> Andreas
>> ​
>>
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston 1.8.0: touch input using evdev not working

[Vikas Patil]

Hi Andreas,

Thanks for inputs. Below is the requested information. I will check if I
can upgrade systemd from 208 to 221.

Do the system need to have udevd --daemon running ? I think my system uses
mdev.

root@linux:~# cat /sys/devices/virtual/input/input0/event0/device/properties
2
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/
abs  ev   ff   key  led  msc  rel  snd  sw
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/key
400 0 0 0 0 0 0 0 0 0 0
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/abs
6618000 3
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/ev
b
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/ff
0
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/led
0
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/msc
0
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/snd
0
root@linux:~# cat
/sys/devices/virtual/input/input0/event0/device/capabilities/sw
0

Thanks & Regards,
Vikash

On Tue, Sep 29, 2015 at 12:02 AM, Andreas Pokorny <
andreas.poko...@canonical.com> wrote:

> Hi,
> Could you send the contents of the files
> /sys/devices/virtual/input/input0/event0/{capabilities/*,properties}? Those
> show the information interpreted by the builtin rules in udevadm. But
> Benjamin might be right, upgrading to systemd-221 might fix your problem
> already.
>
> regards
> Andreas
> ​
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston 1.8.0: touch input using evdev not working

[Vikas Patil]

Hi Benjamin,


I tried to create the custom rule to new file
"/etx/udev/rules.d/01-touchscreen.rules" and also with exixting file with
following content but it is not showing with udevadm and touch still not
working.

ACTION=="add", KERNEL=="input[0-9]*", SUBSYSTEM=="input",
ENV{ID_INPUT}=="1", ENV{ID_INPUT_TOUCHSCREEN}=="1" ATTRS{name}
=="mxt540e_i2c"
or
ACTION=="add", KERNEL=="input*", SUBSYSTEM=="input", ENV{ID_INPUT}=="1",
ENV{ID_INPUT_TOUCHSCREEN}=="1" ATTRS{name} =="mxt540e_i2c"
or
ACTION=="change", KERNEL=="event*", SUBSYSTEM=="input", ENV{ID_INPUT}=="1",
ENV{ID_INPUT_TOUCHSCREEN}=="1" ATTRS{name} =="mxt540e_i2c"
or
ACTION=="change", KERNEL=="event[0-9]*", SUBSYSTEM=="input",
ENV{ID_INPUT}=="1", ENV{ID_INPUT_TOUCHSCREEN}=="1" ATTRS{name}
=="mxt540e_i2c"

and some many more options too.

Is there anything wrong with above lines? or Could you help me to create
the custom rule for my touch device?

I am using systemd (version 208).


Some more information on touch device on platform

root@llinux:/etc/udev/rules.d# udevadm info -a -n /dev/input/event0

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/input/input0/event0':
KERNEL=="event0"
SUBSYSTEM=="input"
DRIVER==""

  looking at parent device '/devices/virtual/input/input0':
KERNELS=="input0"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="mxt540e_i2c"
ATTRS{phys}==""
ATTRS{uniq}==""
ATTRS{properties}=="2"

root@linux:~# cat /proc/bus/input/devices
I: Bus= Vendor= Product=0000 Version=
N: Name="mxt540e_i2c"
P: Phys=
S: Sysfs=/devices/virtual/input/input0
U: Uniq=
H: Handlers=event0
B: PROP=2
B: EV=b
B: KEY=400 0 0 0 0 0 0 0 0 0 0
B: ABS=6618000 3


Thanks & Regards,
Vikash

On Fri, Sep 25, 2015 at 6:38 PM, Benjamin Tissoires <
benjamin.tissoi...@gmail.com> wrote:

>
>
> On Fri, Sep 25, 2015 at 8:20 AM, Vikas Patil <vikasmpa...@gmail.com>
> wrote:
> > Hi Benjamin,
> >
> > First of all thank a lot for your quick response.
> >
> > It means since weston 1.7.0 libinput is by default enabled and only the
> > input backend. I need not to set any specific build switch for it. So in
> > that case I am using libinput. I thought "BUILD_LIBINPUT_BACKEND" still
> > exists and as I haven't set it so thought not using libinput.
>
> OK makes sense. But since 1.7.0, the code supporting non libinput devices
> has been pruned from weston, so the BUILD_LIBINPUT_BACKEND flags does not
> apply anymore.
>
> >
> > What do  you mean by we need to fix the kernel? Does that mean libinput
> > support also requires modification in linux kernel (i.e tocuhscreen
> driver
> > or evedev or somethign else)?
>
> Normally, there is no need to fix the kernel in 90% of the cases. I
> thought your device was not exported properly by the kernel, and the udev
> internal rule for input was not picking it up as it should.
>
> However, after looking at your records, it seems your kernel is fine. The
> problem you are seeing is that udev does not tag your device as a
> touchscreen and libinput ignores it.
>
> > How should I start doing this? Do I need to upgrade to latest version of
> > libudev/libevedev?
>
> Please update udev or add a custom udev rule to add:
>  ID_INPUT=1
>  ID_INPUT_TOUCHSCREEN=1
>
> To your device.
>
>
> >
> > Attached here the output of following two commands.
> >
> > root@linux# evemu-describe /dev/input/event0 > mydevice.desc
> > root@linux# evemu-record /dev/input/event0 > mydevice.events
> >
> > Just for information, Touch screen works fine with weston 1.6.0/weston
> 1.5.0
> > with this kernel.
>
> Yes. It kind of makes sense. However, switching to a full udev discovery
> allows us to remove the heuristics to decide whether a device is a mouse,
> keyboard, touchscreen, etc... to udev, and allows the user to override it
> if the heuristic fails.
> That's why we use udev.
>
> In previous weston builds, the heuristic was in weston, and that's why it
> was working.
>
> Cheers,
> Benjamin
>
> >
> > Thanks & Regards,
> > Vikash
> >
> > On Fri,

Weston 1.8.0: touch input using evdev not working

[Vikas Patil]

Dear Members,



I am trying Weston 1.8.0 on i.MX6 with Freescale linux 3.14.28 and seems
that touch input is not working for me. Weston.log show the following
messages. I am not using llibinput backend yet.



Could anyone give some inputs/suggestion to fix this? Is this due to
following ckeck-in?



http://lists.freedesktop.org/archives/wayland-devel/2015-June/022411.html



*[00:00:50.248] input device 'mxt540e_i2c', /dev/input/event0 not tagged as
input*

*[00:00:50.248] failed to create input device '/dev/input/event0'.*

*[00:00:50.249] warning: no input devices on entering Weston. Possible
causes:*

*- no permissions to read /dev/input/event**

*- seats misconfigured (Weston backend option 'seat', udev device
propert*





I can see “/dev/input/event0” already there and all the touch drivers and
dependencies (i.e. mxt540e.ko, input_polldev.ko, evdev.ko) are loaded.



*root@linux:~# udevadm info /dev/input/event0*

*P: /devices/virtual/input/input0/event0*

*N: input/event0*

*E: DEVNAME=/dev/input/event0*

*E: DEVPATH=/devices/virtual/input/input0/event0*

*E: MAJOR=13*

*E: MINOR=64*

*E: SUBSYSTEM=input*



Thanks & Regards,

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