[PATCH 1/6] Add weston randr protocol

[Pekka Paalanen]

On Thu, 27 Feb 2014 09:15:55 +0000
"Wang, Quanxian" <quanxian.wang at intel.com> wrote:

> 
> 
> -----Original Message-----
> From: Pekka Paalanen [mailto:ppaalanen at gmail.com] 
> Sent: Thursday, February 27, 2014 4:36 PM
> To: Wang, Quanxian
> Cc: wayland-devel at lists.freedesktop.org; Zhang, Xiong Y
> Subject: Re: [PATCH 1/6] Add weston randr protocol
> 
> On Thu, 27 Feb 2014 08:06:23 +0000
> "Wang, Quanxian" <quanxian.wang at intel.com> wrote:
> 
> > 
> > 
> > -----Original Message-----
> > From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
> > Sent: Thursday, February 27, 2014 3:28 PM
> > To: Wang, Quanxian
> > Cc: wayland-devel at lists.freedesktop.org; Zhang, Xiong Y
> > Subject: Re: [PATCH 1/6] Add weston randr protocol
> > 
> > On Thu, 27 Feb 2014 11:28:00 +0800
> > Quanxian Wang <quanxian.wang at intel.com> wrote:
> > 
> > > Weston protocol wrandr will provide interface to
> > > 1) set output mode
> > > 2) set output transform
> > > 3) move output to relative position
> > > 4) provide disconnected display port information
> > > 
> > > *Dynamic* mode setting is the main objective of this protocol.
> > > Remember, it is one shot operation. For example, if setting the 
> > > mode, just call one request wl_randr_set_mode without any other 
> > > operation.
> > 
> > Hi,
> > 
> > like I said in my other reply, this is a configuration interface,
> > not something for all applications to use. Protocol comments below 
> > assuming, that this will be a configuration interface and that the 
> > generic idea is acceptable.
...
> > If I change the mode on two different outputs, how do I know which 
> > action_done corresponds to which request? [Wang, Quanxian] right,
> > add wl_output parameter.
> 
> No. If I do two mode set operations on the same wl_output, then again
> I would not know which answer was for which. [Wang, Quanxian] I know
> you mean. Yes, if the same client has more threads which send mode
> change at the same time, we have to use unique number to stand for
> every operation.

That unique number could be a serial, but here more appropriate is a
unique number for each request. You can let Wayland do all the unique
number management for you by using the feedback object design I
referred to below. After all, a Wayland protocol object is essentially
just a unique number. They are very cheap.

That is why you almost never need to manually fiddle with "unique
numbers" in the protocol.

> Instead, a generic pattern for this kind of "return data" is to let
> the original request also create a feedback protocol object. This
> object is unique to the request that was sent, and can deliver any
> return data without any ambiguity. An example of a feedback object is
> wl_callback, except it can only deliver "done", not "yes"/"no"; not
> delivering anything will cause problems. [Wang, Quanxian] Good,
> thanks.
> 
> > 
> > What if move succeeds but mode change fails? Wouldn't that leave
> > the output in an unwanted state which is neither the original nor
> > the wanted setting? [Wang, Quanxian] one by one. Not support
> > complex. If you have such case, have to turn back. Call another
> > move back. But firstly make sure the previous is successful.
> 
> That will require a lot of roundtrips, and it essentially forces the
> compositor to show all the intermediate steps on the monitors. IOW,
> that is designed to be both slow and glitchy. That's not how you
> should do dynamic mode setting. I think you are going to need atomic
> group operations. [Wang, Quanxian] Yes, we could provide a request
> with more parameters setting(group operations). Just like many
> parameters in weston_output_switch_mode.

Except you would need to let it cover an arbitrary number of outputs in
one go. That means that you will need something like what
wl_surface.commit does. Having a request with a huge number of
arguments is not only ugly but inflexible, and cannot be extended in
the future.

> > The solution to this would tie in with the solution to take changes 
> > atomic. For instance, to prepare for a configuration change, one
> > might create a change object in the protocol, store all changes in
> > that object, and then commit that set of changes atomically. Then
> > have one return value: the whole set either succeeds or fails.
> > 
> > I guess you could look for inspiration in the DRM atomic mode
> > setting API. I don't know how the RandR X11 protocol works, if that
> > would be a good example also.

Thanks,
pq