[PATCH wayland-protocols v5] text: Create second version of text input protocol
ueno at gnu.org
Wed Mar 30 06:13:47 UTC 2016
Bill Spitzak <spitzak at gmail.com> writes:
> On Fri, Mar 25, 2016 at 12:16 AM, Daiki Ueno <ueno at gnu.org> 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
> 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
More information about the wayland-devel