[PATCH 1/6] Add weston randr protocol
quanxian.wang at intel.com
Thu Feb 27 01:58:58 PST 2014
From: Pekka Paalanen [mailto:ppaalanen at gmail.com]
Sent: Thursday, February 27, 2014 5:45 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 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,
> > 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.
[Wang, Quanxian] Agree, I have found that when using this. Basically I want to add transform parameter, at last I give up. because it is complex, also ugly, and not readable. :)
> > 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.
More information about the wayland-devel