Independent clone mode

[Barry Song]

Pekka Paalanen <ppaalanen at gmail.com> 于2019年8月3日周六 上午12:24写道：

>
> On Wed, 31 Jul 2019 09:48:07 +1200
> Barry Song <21cnbao at gmail.com> wrote:
>
> > Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月27日周六 下午8:20写道：
> > >
> > > On Fri, 26 Jul 2019 08:58:42 +1200
> > > Barry Song <21cnbao at gmail.com> wrote:
> > >
> > > > Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月26日周五 上午3:30写道：
> > > > >
> > > > > On Thu, 25 Jul 2019 13:00:55 +1200
> > > > > Barry Song <21cnbao at gmail.com> wrote:
> > > > >
> > > > > > Pekka Paalanen <ppaalanen at gmail.com> 于2019年7月24日周三 下午8:10写道：
> > > > > > >
> > > > > > > On Wed, 24 Jul 2019 13:22:43 +0800
> > > > > > > zou lan <nancy.lan.zou at gmail.com> wrote:
> > > > > > >
> > > > > > > > Hi pekka
> > > > > > > >
> > > > > > > > I see the clone mode is supported from this commit message.
> > > > > > > > https://patchwork.freedesktop.org/patch/227970/
> > > > > > > >
> > > > > > > > I also see the message  "Independent CRTC clone mode cannot be supported
> > > > > > > > until output layout logic is moved from libweston into the frontend and
> > > > > > > > libweston's damage tracking issues stemming from overlapping outputs are
> > > > > > > > solved".
> > > > > > > >
> > > > > > > > I want to ask is independent CRTC clone mode already supported in Weston  6
> > > > > > > > or 7? If not,
> > > > > > > > is there a plan to support it?
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > no, that commit message is still accurate. I don't know of any
> > > > > > > plans to work on independent CRTC clone mode.
> > > > > >
> > > > > > Pekka,
> > > > > > any possible workaround do you know to support independent crtc clone
> > > > > > within weston? right now it is very important product feature.
> > > > > > for example, force weston to identify only one screen, and sync copy
> > > > > > the screen to 2nd screen and call the drm api of 2nd screen?
> > > > >
> > > > > Hi,
> > > > >
> > > > > you could hack it up to do that, but it would be in no way an
> > > > > upstreamable solution. It would also hurt display timings because
> > > > > every repaint would have to wait for both monitors to refresh. Or,
> > > > > all but one monitor would tear.
> > > > >
> > > > > A simpler hack would be to create overlapping outputs and
> > > > > force them repaint fully on every refresh instead of repainting
> > > > > only the damage. That's not upstreamable either, but the damage
> > > > > could be hacked with probably a one-liner.
> > > >
> > > > Hi Pekka,
> > > > Thanks. even though i have seen many times that damage tracking of
> > > > overlapping outputs is the main cause stopping weston from supporting
> > > > full clone mode, i haven't fully understood what is overlapping
> > > > outputs in weston and found the code related with overlapping output,
> > > > would you like to point out some code path so that i can begin to do
> > > > some work on it? pls forgive me if you think the question is just
> > > > stupid.
> > >
> > > Hi,
> > >
> >
> >
> > i made a very great progress to hack weston to support clone mode in
> > the direction you pointed out.
> >
> > it works very well without any tearing.
>
> Hi,
>
> sorry, I did not mean tearing. I meant areas with outdated content.
>
> I guess the best way to make that clearly visible is to have the
> outputs overlap by 50%, not 100%, and then continuously move a window
> such that it will cross all four areas:
> - output A: exclusive area
> - output A: shared with output B area
> - output B: shared with output A area
> - output B: exclusive area
>
> Then observe inconsistency in the image between the exclusive and the
> shared area on each output separately. If you see the window decimate
> on either output, that's bad.
>
> Mind that the effect is semi-random, because it depends on the timings
> of the outputs and the client and desktop updates.
>
>
> > > what I suggested is not about code for overlapping outputs at all.
> > > I'm simply suggesting to hack e.g. weston_output_repaint() or
> > > something to ignore the accumulated damage and use full damage
> > > instead. I can't tell you exactly what and where without doing it
> > > myself first, which I cannot do at the moment.
> >
> > hacked by:
> >
> > @@ -2406,13 +2406,20 @@ weston_output_repaint(struct weston_output
> > *output, void *repaint_data)
> >                 }
> >         }
> >
> > -       compositor_accumulate_damage(ec);
> > +       if (!output->external) {
> > +               compositor_accumulate_damage(ec);
> >
> > -       pixman_region32_init(&output_damage);
> > -       pixman_region32_intersect(&output_damage,
> > -                                 &ec->primary_plane.damage, &output->region);
> > -       pixman_region32_subtract(&output_damage,
> > -                                &output_damage, &ec->primary_plane.clip);
> > +               pixman_region32_init(&output_damage);
> > +               pixman_region32_intersect(&output_damage,
> > +                               &ec->primary_plane.damage, &output->region);
> > +               pixman_region32_subtract(&output_damage,
> > +                               &output_damage, &ec->primary_plane.clip);
> > +       }  else {
> > +               /** From Pekka Paalanen: the damage could be hacked
> > with probably
> > +                * a one-liner, ignore the accumulated damage and use
> > full damage
> > +                */
> > +               output_damage = output->region;
> > +       }
>
> That is not enough, unless you also stopped clearing the damage in the
> external case.

seen a patch, but it seems it has never been applied?

https://lists.freedesktop.org/archives/wayland-devel/2014-March/013571.html

>
> That assignment is also wrong: assigning regions like that is prone to
> memory corruption.
>
> > since so many people are asking for clone mode in weston. would this
> > hacking version be accepted as an initial patch to support independent
> > clone?
>
> I would not take it, sorry.
>
>
> Thanks,
> pq

Thanks
barry