Thanks, Pq
>-----Original Message----- >From: wayland-devel [mailto:[email protected]] On >Behalf Of Pekka Paalanen >Sent: Wednesday, March 26, 2014 3:54 PM >To: Wang, Quanxian >Cc: [email protected] >Subject: Re: weston: weston randr protocol for testing and configuration > >On Wed, 26 Mar 2014 06:47:50 +0000 >"Wang, Quanxian" <[email protected]> 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:[email protected]] >> >Sent: Saturday, March 22, 2014 8:20 PM >> >To: Wang, Quanxian >> >Cc: [email protected] >> >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. Thanks, Pq. > >> >> >> >> For example >> >> In client: >> >> randr_resource = >> >> wl_randr_set_transform(randr.randr,wayland_output,argument.transfor >> >> m); 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. [Wang, Quanxian] That is fine. I am working on that. > >Sorry I haven't had the time to look at your latest series yet. [Wang, Quanxian] That is fine. I also need more time to understand how to make weston randr more extensible and flexible. I am still working on your good ideas. More code need to be read and get more idea to implement weston randr. When it is ready, I will send it out for review continually. Your idea is greatly appreciate. Thanks. > > >Thanks, >pq >_______________________________________________ >wayland-devel mailing list >[email protected] >http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
