-----Original Message----- From: Pekka Paalanen [mailto:ppaala...@gmail.com] Sent: Thursday, February 27, 2014 5:45 PM To: Wang, Quanxian Cc: wayland-devel@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.w...@intel.com> wrote: > > > -----Original Message----- > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > Sent: Thursday, February 27, 2014 4:36 PM > To: Wang, Quanxian > Cc: wayland-devel@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.w...@intel.com> wrote: > > > > > > > -----Original Message----- > > From: Pekka Paalanen [mailto:ppaala...@gmail.com] > > Sent: Thursday, February 27, 2014 3:28 PM > > To: Wang, Quanxian > > Cc: wayland-devel@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.w...@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. [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. Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel