Bill Spitzak <[email protected]> writes: > On Fri, Mar 25, 2016 at 12:16 AM, Daiki Ueno <[email protected]> wrote: > > > > + <description summary="update state"> > > + Allows to atomically send state updates from client. > > + > > + This request should follow after a batch of state updating requests > > + like set_surrounding_text, set_content_type, set_cursor_rectangle and > > + set_preferred_language. > > This sentence indicates that the request is used for some sort of > synchronization between the client and compositor. I'm wondering if it > could perform a roundtrip using wl_callback, instead of generating a > serial on the client side. Then the serial could later be obtained from > the compositor through wl_callback.done. Would that cause any race > conditions? > > > It's not a synchronization, all the requests are going from client to server. > It is to batch them or > make them atomic, or as the wl_surface calls it, it is to double-buffer the > requests.
Sorry for the belated response. Just to be clear: the update_state request itself is not a synchronization, yes. However, there is an implicit synchronization where the serial passed by the update_state request is sent back to the client by the subsequent events like preedit_string or commit_string. This is to ensure the validity of the states set by the preceding set_* requests. I'm actually not sure which is better: using client-generated serials or roundtrip, nor whether it is possible to avoid the statefulness. Even then, I guess an explicit roundtrip here would make the implementation a bit easier. Regards, -- Daiki Ueno _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
