weston: weston randr protocol for testing and configuration

[Jasper St. Pierre]

Yes. I'd say that realistically, you should never have more than one client
trying to set the mode at once. If you somehow do, your machine is already
messing up in some way. No need to design for a broken edge case in the
protocol.

Relying on message ordering is fine. We, of course, still want a commit for
when we have atomic modesetting, but I don't think we need a separate
object.


On Wed, Mar 26, 2014 at 6:54 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140326/6419a2a8/attachment.html>