how to handle the last_error of wl_display
zou lan
nancy.lan.zou at gmail.com
Thu Jun 21 03:59:57 UTC 2018
Hi pekka
I find the last_error is caused by
wl_display_flush()-->wl_connection_flush(). The sendmsg() return fail.
Many applications write code like this:
redraw()
{
wl_surface_commit();
wl_display_sync();
wl_display_flush();
}
while (1) {
redraw();
}
The code will block to wait buffer release event if there is no free
buffer. But if display->last_error happen, the wl_display_dispatch_queue()
fail too. Does the application use the wl_display_flush() right?
Thank you!
Best Regards
Nancy
2018-06-14 18:33 GMT+08:00 Pekka Paalanen <ppaalanen at gmail.com>:
> On Thu, 14 Jun 2018 16:59:35 +0800
> zou lan <nancy.lan.zou at gmail.com> wrote:
>
> > Dear pekka & All:
> >
> > I find a wayland application report error about allocate memory fail.
> > I check the code, after request to weston to allocate dma buffer, it call
> > wl_display_roundtrip().
> > But this function return very fast, it doesn't block until the create
> > events back.
> >
> > I suspect the display->last_error is not 0. Then the
> wl_display_roundtrip()
> > return fast because of the last_error. Does it right?
>
> Hi,
>
> sounds plausible.
>
> > I find the following log:
> >
> > wl_display at 1: error 0: invalid object 10
>
> Your application has a bug.
>
> > Does the application need to handle the display errors? How could I make
> > the last_error not impact wl_display_roundtrip?
>
> All protocol errors are always fatal: they cause the client to be
> disconnected and render the client wl_display unusable. The application
> can only report the error somewhere and quit.
>
> Protocol errors always imply a bug. Usually the bug is in the client
> code, but it could be in compositor code as well.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180621/761e36a7/attachment.html>
More information about the wayland-devel
mailing list