weston: weston randr protocol for testing and configuration

[Wang, Quanxian]

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.

>>
>> 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.

>Thanks,
>pq