Hi, On 28 February 2013 20:02, Sam Spilsbury <[email protected]> wrote:
> Because all of the data has been read from the fd, there is a > condition where we have read every single event that needed to be > delivered to us. Then when we return to poll (), it will block > indefinitely because there is nothing left in the fd for us to read, > and the compositor isn't going to send us any more events. It might be > possible to work around this by checking if events are available in > the queue and calling poll () if there aren't any, but it seems like > there is no API available to do so. > wl_display_dispatch_pending() will dispatch any events which have been read but not acted upon, in the default event queue. The documentation for that function has more information about that exact usecase. > I wanted to know what the expected behaviour around this was meant to > be. If eglSwapBuffers is meant to read () the fd, then that means that > we need to rely on it being called in order to populate the event > queue (since it can only be done in one place). That, in my opinion, > feels like broken behaviour, because we might want to use the protocol > to send data to clients which wouldn't necessarily result in a > SwapBuffers, then those clients can't reliably call either > wl_display_dispatch_pending () or wl_display_dispatch () with poll () > because there's no way of knowing whether or not that fd is going to > block indefinitely or not. > Huh? wl_display_dispatch_pending() never blocks. Hence the suggestion to call it immediately before going into epoll/poll/select. I guess I can make a few suggestions here... > > 1. eglSwapBuffers could read a separate fd for new buffer info > Can't be done, as there are no cross-client resources. > 3. For roundtrip and SwapBuffers, we could make the server put some > data back into the fd indicating that the fd has been read and events > were put into the queue. That way, when main loops call poll () again, > they will see data is available for reading -> wl_display_dispatch > would read that "data", find no new events and dispatch the existing > queue. Then if we don't SwapBuffers again and truly have no remaining > events to be delivered, the next call to poll () would truly sleep > until there was. > Ugh, that sounds nasty and trouble-prone. Cheers, Daniel
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
