Pekka Paalanen <ppaala...@gmail.com> 于2019年8月3日周六 上午12:24写道:
> > On Wed, 31 Jul 2019 09:48:07 +1200 > Barry Song <21cn...@gmail.com> wrote: > > > Pekka Paalanen <ppaala...@gmail.com> 于2019年7月27日周六 下午8:20写道: > > > > > > On Fri, 26 Jul 2019 08:58:42 +1200 > > > Barry Song <21cn...@gmail.com> wrote: > > > > > > > Pekka Paalanen <ppaala...@gmail.com> 于2019年7月26日周五 上午3:30写道: > > > > > > > > > > On Thu, 25 Jul 2019 13:00:55 +1200 > > > > > Barry Song <21cn...@gmail.com> wrote: > > > > > > > > > > > Pekka Paalanen <ppaala...@gmail.com> 于2019年7月24日周三 下午8:10写道: > > > > > > > > > > > > > > On Wed, 24 Jul 2019 13:22:43 +0800 > > > > > > > zou lan <nancy.lan....@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel