weston: weston randr protocol for testing and configuration

[Pekka Paalanen]

On Wed, 26 Mar 2014 10:15:31 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> Thanks, Pq
> 
> >-----Original Message-----
> >From: wayland-devel [mailto:wayland-devel-bounces at lists.freedesktop.org] On
> >Behalf Of Pekka Paalanen
> >Sent: Wednesday, March 26, 2014 3:54 PM
> >To: Wang, Quanxian
> >Cc: wayland-devel at lists.freedesktop.org
> >Subject: Re: weston: weston randr protocol for testing and configuration
> >
> >On Wed, 26 Mar 2014 06:47:50 +0000
> >"Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> >
> >> Hi, Pq
> >>
> >> In weston randr v2, I don't include the following question. I am still in confused.
> >Sorry about that.
> >>
> >> >-----Original Message-----
> >> >From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> >> >Sent: Saturday, March 22, 2014 8:20 PM
> >> >To: Wang, Quanxian
> >> >Cc: wayland-devel at lists.freedesktop.org
> >> >Subject: Re: weston: weston randr protocol for testing and
> >> >configuration
> >> >
> >> >
> >> >Talking about threads here is misleading. Such threaded operations do
> >> >not make sense to begin with. The question is more about ambiguity
> >> >between operations and acknowledgements, and preferring explicit
> >> >correspondence than relying on protocol message ordering.
> >> >So the goal is good, but the rationale is slightly wrong.
> >> >
> >> [Wang, Quanxian] For this issue, I am still confused Supposed that case, the first
> >client is doing the randr without commit, however the second commit his request.
> >This will breakdown the first client if they works on the same output.
> >> My suggestion is that allocating a request id for every request set. (first client
> >request set, second client request set, .. etc), everyone could not break down
> >others operation before commit. Otherwise clients will not control his actions.
> >> Even in callback, you must don't want to get the callback done event when you
> >are doing the action without commit.
> >>
> >
> >Hi,
> >
> >clients cannot and must not ever interfere with each other. On the protocol level,
> >they simply cannot interfere, because all protocol objects are private to a client
> >(connection).
> >
> >As long as you keep all uncommitted state as per protocol object (wl_resource in
> >the server), there cannot happen any mixups. In other words, the not yet
> >committed state should not be stored in struct weston_output, but in some new
> >struct that is created per wl_output protocol object. This seems to require
> >replacing weston_output::resource_list with a new list, maybe.
> >
> >There is no reason to create "request ids" at all.
> >
> >The only thing you need, is that the commit request creates a protocol object, that
> >will then deliver the result of the commit. This is very similar to how
> >wl_surface.frame creates a new object, that then delivers the 'done' event. The
> >difference to wl_surface is only that the commit creates the object, not a separate
> >request, and the delivered event is different.
> >
> >Even that is not strictly necessary, but it makes a nicer API for clients than just
> >relying on the order of received events when the result event was just in the
> >global interface.
> >
> >I don't really understand what your concerns are, so maybe I didn't reply to them?
> [Wang, Quanxian] Actually, I am worry about the multiple threads and clients to avoid the conflict. They maybe work on the same output.
> I think I should think about that since it is a protocol for every client. But your comment make me clear more and more. I will refer to wl_surface code to check how to make it happen.

Well, multiple threads changing the mode of the same output is just
rubbish. So sane program will ever do that, so there is no reason make
that behaviour race-free or well-defined. That is why I would not say,
that supporting multiple threads doing mode switches is a reason behind
this design.

What we do want to have, is that a single-threaded client alone doing a
series of mode set operations will be sure of which reply is for which
commit. We could rely on protocol message ordering, but we also
have a design pattern to make the association explicit: the commit
request can create a new protocol object, that will then deliver the
reply. The identity of that object identifies the set of changes.

If you have several clients racing to set the mode (which you should
never have, anyway), following the design pattern of queueing state
changes and then committing them all at once will keep the states from
different clients from mixing up. The client that does the commit last
will have its complete state set last. The race makes only the parts of
output state a client is not setting undefined, because the other
commit may have changed them. There is no need to eliminate this race,
because it is really a user error.

If you define, that a set of state changes can include changes to
multiple outputs and not just one output, meaning that a commit can
change all outputs in one go, then we could live well without the reply
protocol object. Now I think this would be preferred; protocol for
completely atomic modesetting over all outputs. It would be simple
protocol-wise, too.


Thanks,
pq