Dual display in clone mode or extended mode with Weston

[Pekka Paalanen]

On Fri, 22 Jun 2018 10:42:12 +0300
Konstantin Kharlamov <hi-angel at yandex.ru> wrote:

> On 21.06.2018 21:44, Matheus Santana wrote:
> > 
> > 
> > On Thu, Jun 21, 2018 at 5:11 AM, Pekka Paalanen <ppaalanen at gmail.com 
> > <mailto:ppaalanen at gmail.com>> wrote:
> > 
> >     On Wed, 13 Jun 2018 17:40:59 +0530
> >     Ashvini Deshmukh <ashvini2781 at gmail.com
> >     <mailto:ashvini2781 at gmail.com>> wrote:
> >   
> >     > Hello All,
> >     > 
> >     > I have read queries for dual display on freedesktop.org <http://freedesktop.org>
> >     > 
> >     > I need your help in the same context.
> >     > 
> >     > Currently we are creating one application to support multiple displays with
> >     > Wayland.  
> > 
> >     Hi,
> > 
> >     you are developing an application, ok. I assume that means a Wayland
> >     client specifically.
> >   
> >     > We are unaware that one compositor will be sufficient for dual display.  
> > 
> >     Sorry, I don't understand. Are you asking whether one Wayland
> >     compositor could driver multiple displays? Yes, they can in general.
> >     Capabilities will vary between different compositor implementations.
> >   
> >     > We need to know about how virtual framebuffer is created per display.  
> > 
> >     As an application developer, why would you care about that? That is a
> >     compositor internal implementation detail.
> > 
> >     Why virtual? Real outputs do not have virtual framebuffers, they have
> >     real framebuffers as far as the compositor is concerned.
> >   
> >     > As DRM supports only one compositor,
> >     > How to display same content on second display OR can we have different user
> >     > events on second display monitor.  
> > 
> >     What do you mean?
> > 
> >     If a Wayland compositor supports and has been configured to show the
> >     same content on multiple displays, then it will do that. From a Wayland
> >     client perspective, there is nothing you need to do to have your
> >     window show up on cloned displays compared to a single display case.
> > 
> >     By user events, do you mean input events?
> > 
> >     It is certainly possible to write a compositor that dedicates one set
> >     of input devices for one display and another set of input devices for
> >     the other display.
> > 
> >     Applications are expected to support multiple wl_seat globals (similar
> >     to multi-pointer X in essence). There is nothing else they would need
> >     to specifically support for a compositor that had multiple outputs,
> >     cloned outputs, or divided input devices in any arbitrary way.
> > 
> >     I did not understand your requirements well enough to say how well
> >     Weston would work for you.
> > 
> >     For example, Weston currently does not support multiple KMS devices,
> >     but it does support multiple displays on a single KMS device. Support
> >     for multiple KMS devices is desired in Weston though, so maybe it will
> >     in the future.
> > 
> > 
> > I'm curious about what you specifically mean by KMS device. Each 
> > graphics card?

Hi,

if you only know of PC computers, yes, it is the graphics card.
However, the term "graphics card" is generally a vague concept.

By KMS device I refer to the /dev/dri/card* device nodes, which support
mode setting (KMS). For PC graphics cards, this same device node offers
both the display hardware and the GPU features (the same GPU features
are additionally exposed also through a render node). But, especially
on embedded boards, the display hardware and GPU hardware blocks often
come from different vendors which means they have separate drivers, and
that makes it more natural to expose those as two separate device
nodes: a KMS device node (card*) for display hardware, and a card*
and/or a render node (render*) for the GPU.

Currently, Weston is able to open only one KMS device node at a time.
Making use of the GPU, whether that is exposed through the same or a
different device node, is left as a detail for the EGL implementation.

> > 
> > I've just tried Weston with two displays and it worked out on the fly 
> > ("extended mode").
> > 
> > 
> >     Weston's clone mode is currently limited to sharing a CRTC between all
> >     displays, assuming someone reviews the final patch needed to configure
> >     it. Support for this configuration does not seem to be common among PC
> >     graphics hardware, embedded boards may have better chances.
> > 
> > 
> > What does CRTC stand for?  
> 
> In this context, AFAIR, "CRTC" means a device that scans out an image 
> from a buffer to a display. The acronym is historical, stands for 
> "cathode ray tube controller".

Correct. In this particular case it refers to the abstract object
called a "CRTC" as exposed by the kernel KMS API. It has a framebuffer
associated from which it reads the image, and it generates the video
signal timings according to the video mode set to it.

In the API model, the data stream generated by a CRTC is routed through
an "encoder" which converts the abstract video data stream into an
actual video signal, e.g. HDMI, which then goes out through a
"connector" (the API object representing an actual physical connector).
The model allows feeding one or more encoders and connectors from the
same CRTC; this is the flavour of clone mode implemented in Weston. All
displays in this clone mode will share the exact same contents, video
mode and timings.


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/20180625/5a1b682f/attachment-0001.sig>