<div dir="ltr"><div dir="ltr"><div dir="ltr">Hi pekka</div><div dir="ltr"><br></div><div>I check the atomic commit part of the drm backend in weston 5.0. But I am not sure if some vendors support one atomic commit to update many CRTCs, so I was wondering</div><div>if one output repaint to do one atomic commit would match the weston 5.0's architecture if they don't support it. I think the answer it's yes, is it right?</div><div><br></div><div>I also have another question about the function output_repaint_timer_arm() in compositor.c, about the following comment:</div><div dir="ltr"><div><div>/* Even if we should repaint immediately, add the minimum 1 ms delay.</div><div><span style="white-space:pre">        </span> * This is a workaround to allow coalescing multiple output repaints</div><div><span style="white-space:pre">  </span> * particularly from weston_output_finish_frame()</div><div><span style="white-space:pre">     </span> * into the same call, which would not happen if we called</div><div><span style="white-space:pre">    </span> * output_repaint_timer_handler() directly.</div><div><span style="white-space:pre">   </span> */</div></div><div>If the vendor doesn't support commit multi outputs together, does this increase the latency for next repaint? The latency could be larger than 1ms if the timer event can't be</div><div>triggered immediately.</div><div><br></div><div>If the outputs' refresh rate is not the same, is there any problem to repaint multi outputs together?</div><div><br></div><div>Thank you!</div><div><br></div><div>Best Regards</div><div>Nancy</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> 于2018年11月23日周五 下午6:00写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 23 Nov 2018 16:22:56 +0800<br>
zou lan <<a href="mailto:nancy.lan.zou@gmail.com" target="_blank">nancy.lan.zou@gmail.com</a>> wrote:<br>
<br>
> Hi pekka<br>
> <br>
> >>do you mean users as humans or as apps?  <br>
> yes. I mean the apps. I think it's no big impact for apps. The major<br>
> changes for weston new version is focus on libweston/drm backend.<br>
<br>
Hi Nancy,<br>
<br>
Weston and any compositor is always bound by the Wayland protocol<br>
stability promises. The only thing where a compositor implementation<br>
can use its own judgement is which globals it will advertise and will<br>
it implement new versions of existing interfaces. (New versions of<br>
interfaces as denoted by the "version" attribute in the XML are<br>
required to be backwards-compatible.)<br>
<br>
So the only things you need to watch out for are:<br>
- did the compositor stop advertising some global interface<br>
- do you have a client that requires a global interface the compositor<br>
  has never supported yet<br>
- do you have a client that requires a certain minimum version of an<br>
  interface that the compositor does not support yet<br>
<br>
> I still want to ask something about drm backend. About on_drm_input()<br>
> function in compositor-drm.c, do this function plan to listen all CRTCs'<br>
> pageflip/vblank event or only listen<br>
> one primary CRTC's pageflip/vblank event? I think the repaint_flush() want<br>
> to do AtomicCommit for all crtcs one time, does it support commit for each<br>
> output just like the old<br>
> drm backend design in weston 5.0 or latest weston architecture?<br>
<br>
A repaint_flush() call will do an atomic commit involving any number of<br>
outputs (CRTCs). Which outputs happen to be included depends on the<br>
timings of each individual output. It can and will vary on each atomic<br>
commit.<br>
<br>
on_drm_input() handles all DRM events. Depending on libdrm and kernel<br>
support, it can dispatch to page_flip_handler() or<br>
atomic_flip_handler().<br>
<br>
page_flip_handler() is only used on legacy KMS, which means it will<br>
process an event for each drmModePageFlip() call. That is naturally per<br>
CRTC.<br>
<br>
atomic_flip_handler() is only for atomic commits and will also get<br>
called per CRTC by the kernel, not per atomic commit as a whole, and it<br>
carries the CRTC id as an argument. It does not get called for a<br>
TEST_ONLY atomic commit.<br>
<br>
Since someone probably will be hacking around in downstream, I'd would<br>
like to offer a warning. Whatever you do, do not ever add new calls to<br>
drmModeAtomicCommit or call anything that synchronously calls atomic<br>
commit or the legacy KMS functions. The architecture is designed around<br>
first collecting all the state an atomic commit needs, building the<br>
commit, testing it first, and if the test succeeds, only then firing<br>
the real commit. So if you want to control some new property or you<br>
want to turn off a monitor or anything, you have to make that new thing<br>
part of the state machinery and let the state machinery commit it for<br>
you. Anything else will quickly spiral into an unfixable mess.<br>
<br>
It was a huge effort to get rid of the "immediate" libdrm KMS calls and<br>
replace them with the atomic state machine. I recall that temporary<br>
video mode switching and maybe even DPMS might still be not quite there<br>
yet, because their original internal API fit really badly into the<br>
atomic design.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div>