On Fri, 23 Nov 2018 20:12:53 +0800 zou lan <[email protected]> wrote:
> Hi pekka > > 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 Hi Nancy, in my opinion vendors really should support it. If they don't, it leaves one of the big benefits of atomic modesetting unimplemented: the ability to change multiple CRTC-connector-routings reliably. Therefore I would not want Weston to encourage the use of half-made atomic drivers. > I was wondering > 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? Currently Weston does not enable atomic modesetting at all without DRM_CAP_CRTC_IN_VBLANK_EVENT. Could that be used as a flag to see if the driver can accept multi-CRTC atomic commits, or do we need to TEST_ONLY? The Linux commit 5db06a8a98f515f67446a69c57577c4c363ec65d only talks about a field being set correctly, it does not imply that the flag could be used to detect multi-CRTC commit support. Is an atomic driver that doesn't support multi-CRTC atomic commits even a thing, Daniel? > I also have another question about the function > output_repaint_timer_arm() in compositor.c, about the following comment: > /* Even if we should repaint immediately, add the minimum 1 ms delay. > * This is a workaround to allow coalescing multiple output repaints > * particularly from weston_output_finish_frame() > * into the same call, which would not happen if we called > * output_repaint_timer_handler() directly. > */ > 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 > triggered immediately. It shouldn't. If one was to implement strict per-output atomic commits, it shouldn't involve re-arming the timer for each output to be repainted on the same cycle. > > If the outputs' refresh rate is not the same, is there any problem to > repaint multi outputs together? No. If the vblanks of the outputs do not coincide, then they are not put into the same repaint_begin/flush cycle. This is decided separately every time in output_repaint_timer_handler(). Each output will always repaint according to its own timings independently, but if multiple outputs happen to be ready at roughly the same time, they get into the same atomic commit. weston_output_maybe_repaint() decides if the output gets into the atomic commit right now or not. Only in rare occasions, like compositor start-up, will all outputs be forced into the same atomic commit regardless of their timings. This is used to e.g. make the CRTC-connector-routing changes reliable. Thanks, pq
pgpu9_dipIyCN.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
