On Thu, Jun 21, 2018 at 3:44 PM, Matheus Santana <[email protected]> wrote:
> > > On Thu, Jun 21, 2018 at 5:11 AM, Pekka Paalanen <[email protected]> > wrote: > >> On Wed, 13 Jun 2018 17:40:59 +0530 >> Ashvini Deshmukh <[email protected]> wrote: >> >> > Hello All, >> > >> > I have read queries for dual display on 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? > Found the response for this in SoC ideas page <https://www.x.org/wiki/SummerOfCodeIdeas/>: Weston supports multiple outputs, but currently limits them to a single > GPU. Add support to Weston's DRM backend to open several KMS devices, with > the ability to use outputs from all of them. > > > 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? > >> >> >> Thanks, >> pq >> >> _______________________________________________ >> wayland-devel mailing list >> [email protected] >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel >> >> > > Best regards, > Matheus > >
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
