Dual display in clone mode with weston and wayland-ivi-extension

[Pekka Paalanen]

On Fri, 10 Mar 2017 12:14:36 +0530
Vikas Patil <vikasmpatil at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170310/34c56647/attachment.sig>