weston: weston randr protocol for testing and configuration

[Wang, Quanxian]

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