<div dir="ltr"><div dir="ltr"><div dir="ltr">Hello Pekka, <div><br></div><div>Thanks for your inputs and we are able to find further why we are getting the "Protocol Error". </div><div>Please provide you inputs for below query:</div><div><br></div><div>As we are very frequently create and destroy surface, during this at one instance "controller_surface_create" function from ivi-controller.c which tries to create the wl_resources is not able to create the wl_resources, because surface is already destroyed and this function returns without creating the resources from below mentioned part of the function</div><div><br></div><div><div>    layout_surface = lyt->get_surface_from_id(id_surface);</div><div>    if (layout_surface == NULL) {</div><div>        return;</div><div>    }</div></div><div>So, here ivi-controller is not notifying any error event for this.</div><div>as per the ivi-controller.xml, ivi-controller have one error interface that can be set, if any error encountered by ivi-controller interface. <br></div><div>Is there a way by which we can notify the client about the error?</div><div><br></div><div>Attaching ivi-controller.c file for reference.</div><div><br></div><div>Thanks in advance.</div><div><br></div><div>Regards,</div><div>Ikshwkau</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 1, 2019 at 6:11 PM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 31 Dec 2018 20:08:24 +0530<br>
Ikshwaku Chauhan <<a href="mailto:ikshwaku.ec2004@gmail.com" target="_blank">ikshwaku.ec2004@gmail.com</a>> wrote:<br>
<br>
> Hello Pekka,<br>
> <br>
> Thanks for your reply.<br>
> Here we are trying to identify the exact root cause for the protocol error.<br>
> we deliberately dumped the back trace by calling *abort in<br>
> display_protocol_error* function and attaching backtrace for your<br>
> reference.<br>
> Could you please have a look and provide your inputs.<br>
<br>
Hi,<br>
<br>
sorry, I explained my guesses in my previous email, and if those<br>
are true, backtrace of the protocol error is not helpful. You need<br>
to look into when you create, skip creating, or destroy<br>
wl_resources representing ivi_controller_surface objects.<br>
<br>
The bug likely happens before the protocol error: when you are<br>
processing ivi_controller.surface_create or between that and a<br>
request that triggers the protocol error.<br>
<br>
> We have one more query,<br>
> As per the wayland client logs I have attached in the last mail, we<br>
> observed that after getting surface created event, usually we get<br>
> configuration event and then if we set any property of surface (ex:<br>
> set_source_rectangle), the protocol communication seems to be fine.<br>
> But, when surface created event received and without configuration event,<br>
> if we try to set any property of surface, the protocol communication seems<br>
> to be stuck.<br>
<br>
I suppose the compositor is not sending the configuration event for<br>
some reason? Maybe the underlying surface was destroyed immediately<br>
after it was created?<br>
<br>
That is not upstream Weston code, so I cannot know.<br>
<br>
> Is this the expected behavior for "Protocol error"?  Please provide you<br>
> inputs for this as well.<br>
<br>
As said, all protocol errors are instantly fatal and cause the<br>
Wayland connection to become dead. No further messaging will be<br>
possible on a dead connection.<br>
<br>
Events that have been written into the socket before the protocol<br>
error will remain, but the socket is already disconnected.<br>
<br>
<br>
Thanks,<br>
pq<br>
<br>
> On Sun, Dec 30, 2018 at 2:42 PM Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote:<br>
> <br>
> > If I had to guess, you have a compositor-side bug. Either the<br>
> > wl_resource for id 22 in the ivi_controller.surface_create call is<br>
> > not created at all, or it is created and then destroyed unwarranted<br>
> > by the protocol.<br>
> ><br>
> > Whenever a protocol message is creating a new object, the message<br>
> > handler in the compositor cannot ever choose to not create the<br>
> > wl_resource for it. Likewise, wl_resources cannot be destroyed<br>
> > without an explicit warrant from protocol exchange, e.g. a destroy<br>
> > request.<br>
> ><br>
> > I'm guessing that you use global identifiers (the argument 80) to<br>
> > identify surfaces, that "surface 80" does not exist anymore, so you<br>
> > skip creating the wl_resource. That would be a bug.<br>
> ><br>
</blockquote></div>