On Fri, 10 Mar 2017 12:14:36 +0530 Vikas Patil <[email protected]> wrote:
> Dear All, > > Do wayland/weston or wayland-ivi-extension supports dual display in clone > mode? If not, is there any way I can configure weston or > wayland-ivi-extension to operate dual display in clone mode? Hi, sorry, Weston (libweston) does not support clone mode per se. It's a fairly deep rabbit hole. IVI-shell might offer a way by essentially driving the outputs independently, but configuring the scenegraph to be identical to each of them by creating views of a window for each output. That would be up to your "layer manager". I believe this is the only approach in the short term you have available. > Is there any plan to support this? Any suggestions/inputs on How can I > achieve this? You're not the only one needing a proper clone mode, so I might say it is planned, kind of, but effort needed to develop it is measured in man-weeks for someone who is already quite familiar with Weston internals. There are at least three different ways of doing clone mode: 1. A single CRTC driving several encoders/connectors - This is the most power-efficient. - Not always possible due to hardware limitations. - The monitors must have the same video timings and resolution. - The monitors are guaranteed to be frame-locked to always show the same image (unless the monitors themselves have different latencies etc.) 2. Creating framebuffers individually for each CRTC/connector - The most flexible approach: monitors can have different timings, different resolutions, highly different pixel densities, different areas of the desktop to show, etc. - The most power-hungry approach: a compositing pass is needed per monitor per frame. - The monitors run asynchronously to each other (good or bad, depending on what you need). - Requires re-designing Weston's internal damage tracking. 3. Sharing framebuffers between CRTCs - The most complicated approach to implement, because you have several CRTCs running asynchronously, but you still have just one buffer flip queue. - Prone to reduced framerates and framerate jitter. - Might be as power-efficient as option 1, or as wasteful as option 2. - Unclear what the buffer flip queue management algorithm should look like, would probably need a pool of framebuffers rather than just the usual double-buffering to allow updating monitors somewhat independently. - Unclear whether this mode actually has real benefits over the other two. A big portion of the needed effort is designing how the libweston API to configure outputs should look like so that it can support all kinds of clone modes and give the user (the compositor) a full freedom in configuring it while preferably not exposing the full nightmare of CRTCs and connectors. I suspect the output configuration API also needs to change to become atomic so that the user can configure everything and push it in in one go, with a test before final commit to check it actually can work. This will relate to and likely depend on the atomic modesetting patch series. Internally, it involves re-designing what a struct weston_output is, splitting some new objects out of it, and defining their roles and relationships. Some will be exposed in the libweston API, some will be internal. After all that comes the relatively small task of actually writing the DRM-backend code to program the clone mode into the hardware. Thanks, pq
pgpZFKfVBzBZU.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
