weston: weston randr protocol for testing and configuration

[Pekka Paalanen]

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?

> >>
> >> For example
> >> In client:
> >> randr_resource =
> >> wl_randr_set_transform(randr.randr,wayland_output,argument.transform);
> >> wl_randr_add_listener(randr_resource, &randr_transform_listener,
> >> &randr);
> >>
> >> In compositor:
> >> randr_resource = wl_resource_create(client,&wl_randr_interface,1,
> >> action); ...
> >> wl_randr_send_action_done(randr_resource,
> >> 1<<WL_RANDR_ACTION_TRANSFORM, ret, action);
> >> wl_resource_destroy(randr_resource);
> >
> >I do not want a reply for every single part of output state, I want a reply for the
> >final commit request that applies all the state updates gathered so far. That will
> >also solve the atomicity problem.
> >
> >See how wl_surface works, and add a reply object only to the commit request.
> [Wang, Quanxian] Yes, when surface get a commit, it will applies all the state updates gathered so far. And then inform user that (frame callback called after weston_output_repaint), If client is updating the surface and without commit. Suddenly when he got an reply event that surface has update his previous changes. But he didn't run surface_commit at that time. Here I don't understand if there are some conflict. (The reply callback is created by surface_frame to keep tuning of his update.)
> That means compositor does the update when client don't run surface commit. Sorry, I am really confused here. Actually it is the same as above question to avoid the conflict.
> 

The wl_callback from a wl_surface.frame request will never deliver an
event, if the client has not also sent wl_surface.commit following that
particular request.

If there were earlier wl_surface.frame requests that were followed by
wl_surface.commits, then those events can be delivered, of course. The
point is, the client has a unique wl_callback object from every
wl_surface.frame request it did, and so it will explicitly know
for which request it is getting a reply to. That is what I'd like to
see in the randr protocol, too.

Sorry I haven't had the time to look at your latest series yet.


Thanks,
pq