On Wed, 26 Mar 2014 06:47:50 +0000 "Wang, Quanxian" <quanxian.w...@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:ppaala...@gmail.com] > >Sent: Saturday, March 22, 2014 8:20 PM > >To: Wang, Quanxian > >Cc: wayland-devel@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
