question about drm backend

[Pekka Paalanen]

On Fri, 23 Nov 2018 20:12:53 +0800
zou lan <nancy.lan.zou at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181123/12250ca8/attachment.sig>