Hi, I'm a little confused on the behaviour of eglSwapBuffers operating on the event queue. At the moment, it calls wl_connection_read () on the display fd, which will read events into the local event buffer. I imagine it needs to do this in order to fetch some information about the next backbuffer from the compositor. However, it reads all of the events out of the queue, and this has pretty bad consequences for event loops which are trying to integrate the wayland fd into their poll () / select () loop.
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. 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. I guess I can make a few suggestions here... 1. eglSwapBuffers could read a separate fd for new buffer info 2. We could add an API to determine how many events are in the queue right now without reading, though that wouldn't solve the poll () problem 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. Best Regards, Sam -- Sam Spilsbury _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
