wl_buffer is not released for long time.

Thu Mar 15 00:19:10 UTC 2018

Dear Pekka,

Thanks for your idea on this, I inserted a callback in the `surface_commit`
function in libweston. From the log I can see that the `surface commit` was
blocked on the server side until some other events happen. On the client
side it was clear that I committed two buffers then sleeped because of
lacking available buffers. I am using libweston and currently I didn't
setup any input callbacks. All I did was setting up an interface to set
views in background layers then call `wl_display_run()`. I hope to know is
there anyways to follow wayland server event queues in libweston?

Thanks very much,
SZ

Le mer. 14 mars 2018 04 h 49, Pekka Paalanen <ppaalanen at gmail.com> a écrit :

> On Tue, 13 Mar 2018 14:11:29 +0000
> Sichem Zhou <sichem.zh at gmail.com> wrote:
>
> > Dear Matt,
> >
> > I just checked my compiled version, indeed I was using a version without
> > this patch. I patched my local weston but it didn't seem that my problem
> is
> > gone. So I guess there could be other problems with my code, but thanks
> for
> > your assistance. Now I can insert the callback in weston to do some
> > inspection.
>
> Hi,
>
> note that there is no guarantee to get a wl_buffer.release until you
> have wl_surface.committed the next wl_buffer. A compositor could send a
> release without a new buffer, but that is only possible is the
> compositor made a copy of the buffer contents. Compositors try to avoid
> such copies.
>
> It didn't sound like this was your issue, but just reminding.
>
> It sounds more like the compositor might be blocked unnecessarily
> somewhere, and getting input events will let its main event loop
> un-block. This shouldn't happen, but there could be bugs.
>
>
> Thanks,
> pq
>
> > Le lun. 12 mars 2018 19 h 22, Matt Hoosier <matt.hoosier at gmail.com> a
> > écrit :
> >
> > > Here's the discussion and patch that addressed the issue I was
> mentioning:
> > >
> > >
> > >
> https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html
> > >
> > > On Mon, Mar 12, 2018 at 3:51 PM, Matt Hoosier <matt.hoosier at gmail.com>
> > > wrote:
> > > > Hi,
> > > >
> > > > Unless you're using an unreleased version of Weston, I think you're
> > > > probably running into a bug that we fixed a few months ago in which
> > > > wl_buffer::release() events were prone to sit undispatched in the
> > > > server's outgoing queue until some other event happened to need
> > > > transmitted.
> > > >
> > > > -Matt
> > > >
> > > > On Mon, Mar 12, 2018 at 1:23 PM, Sichem Zhou <sichem.zh at gmail.com>
> > > wrote:
> > > >> Hi all,
> > > >>
> > > >> Dear wayland devs, I have a question regarding to double `wl_buffer`
> > > >> management. I don't seem to have wl_buffer released untill some
> other
> > > events
> > > >> triggered (for example, the  inputs). My current environment is
> under
> > > >> `X11-backend` and a libweston based compositor.
> > > >>
> > > >> My pipeline follows: (frame, attach, damage, commit) -> buffer
> switch ->
> > > >> wait until one buffer available -> redraw. The `done` event is
> handled
> > > >> differently since it only signals if ready to draw.
> > > >>
> > > >> Through my experiments, I found out at I wouldn't get either of the
> > > >> `release` of `frame done` event if I wasn't using the compositor
> (moving
> > > >> cursor or typing). In this case I guess there is something wrong
> with my
> > > >> pipeline but I couldn't figure out which. I wish to know if there is
> > > obvious
> > > >> mistakes in my pipeline or the problem lies in the compositor.
> > > >>
> > > >>  Very appreciate any answers.
> > > >>
> > > >> SZ
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> wayland-devel mailing list
> > > >> wayland-devel at lists.freedesktop.org
> > > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > >>
> > >
>
>
Le 14 mars 2018 04 h 49, "Pekka Paalanen" <ppaalanen at gmail.com> a écrit :

On Tue, 13 Mar 2018 14:11:29 +0000
Sichem Zhou <sichem.zh at gmail.com> wrote:

> Dear Matt,
>
> I just checked my compiled version, indeed I was using a version without
> this patch. I patched my local weston but it didn't seem that my problem
is
> gone. So I guess there could be other problems with my code, but thanks
for
> your assistance. Now I can insert the callback in weston to do some
> inspection.

Hi,

note that there is no guarantee to get a wl_buffer.release until you
have wl_surface.committed the next wl_buffer. A compositor could send a
release without a new buffer, but that is only possible is the
compositor made a copy of the buffer contents. Compositors try to avoid
such copies.

It didn't sound like this was your issue, but just reminding.

It sounds more like the compositor might be blocked unnecessarily
somewhere, and getting input events will let its main event loop
un-block. This shouldn't happen, but there could be bugs.

Thanks,
pq

> Le lun. 12 mars 2018 19 h 22, Matt Hoosier <matt.hoosier at gmail.com> a
> écrit :
>
> > Here's the discussion and patch that addressed the issue I was
mentioning:
> >
> >
> >
https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html
> >
> > On Mon, Mar 12, 2018 at 3:51 PM, Matt Hoosier <matt.hoosier at gmail.com>
> > wrote:
> > > Hi,
> > >
> > > Unless you're using an unreleased version of Weston, I think you're
> > > probably running into a bug that we fixed a few months ago in which
> > > wl_buffer::release() events were prone to sit undispatched in the
> > > server's outgoing queue until some other event happened to need
> > > transmitted.
> > >
> > > -Matt
> > >
> > > On Mon, Mar 12, 2018 at 1:23 PM, Sichem Zhou <sichem.zh at gmail.com>
> > wrote:
> > >> Hi all,
> > >>
> > >> Dear wayland devs, I have a question regarding to double `wl_buffer`
> > >> management. I don't seem to have wl_buffer released untill some other
> > events
> > >> triggered (for example, the  inputs). My current environment is under
> > >> `X11-backend` and a libweston based compositor.
> > >>
> > >> My pipeline follows: (frame, attach, damage, commit) -> buffer
switch ->
> > >> wait until one buffer available -> redraw. The `done` event is
handled
> > >> differently since it only signals if ready to draw.
> > >>
> > >> Through my experiments, I found out at I wouldn't get either of the
> > >> `release` of `frame done` event if I wasn't using the compositor
(moving
> > >> cursor or typing). In this case I guess there is something wrong
with my
> > >> pipeline but I couldn't figure out which. I wish to know if there is
> > obvious
> > >> mistakes in my pipeline or the problem lies in the compositor.
> > >>
> > >>  Very appreciate any answers.
> > >>
> > >> SZ
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> wayland-devel mailing list
> > >> wayland-devel at lists.freedesktop.org
> > >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180315/c8f0021f/attachment-0001.html>