question about drm backend

[zou lan]

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
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?

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.

If the outputs' refresh rate is not the same, is there any problem to
repaint multi outputs together?

Thank you!

Best Regards
Nancy

Pekka Paalanen <ppaalanen at gmail.com> 于2018年11月23日周五 下午6:00写道：

> On Fri, 23 Nov 2018 16:22:56 +0800
> zou lan <nancy.lan.zou at gmail.com> wrote:
>
> > Hi pekka
> >
> > >>do you mean users as humans or as apps?
> > yes. I mean the apps. I think it's no big impact for apps. The major
> > changes for weston new version is focus on libweston/drm backend.
>
> Hi Nancy,
>
> Weston and any compositor is always bound by the Wayland protocol
> stability promises. The only thing where a compositor implementation
> can use its own judgement is which globals it will advertise and will
> it implement new versions of existing interfaces. (New versions of
> interfaces as denoted by the "version" attribute in the XML are
> required to be backwards-compatible.)
>
> So the only things you need to watch out for are:
> - did the compositor stop advertising some global interface
> - do you have a client that requires a global interface the compositor
>   has never supported yet
> - do you have a client that requires a certain minimum version of an
>   interface that the compositor does not support yet
>
> > I still want to ask something about drm backend. About on_drm_input()
> > function in compositor-drm.c, do this function plan to listen all CRTCs'
> > pageflip/vblank event or only listen
> > one primary CRTC's pageflip/vblank event? I think the repaint_flush()
> want
> > to do AtomicCommit for all crtcs one time, does it support commit for
> each
> > output just like the old
> > drm backend design in weston 5.0 or latest weston architecture?
>
> A repaint_flush() call will do an atomic commit involving any number of
> outputs (CRTCs). Which outputs happen to be included depends on the
> timings of each individual output. It can and will vary on each atomic
> commit.
>
> on_drm_input() handles all DRM events. Depending on libdrm and kernel
> support, it can dispatch to page_flip_handler() or
> atomic_flip_handler().
>
> page_flip_handler() is only used on legacy KMS, which means it will
> process an event for each drmModePageFlip() call. That is naturally per
> CRTC.
>
> atomic_flip_handler() is only for atomic commits and will also get
> called per CRTC by the kernel, not per atomic commit as a whole, and it
> carries the CRTC id as an argument. It does not get called for a
> TEST_ONLY atomic commit.
>
> Since someone probably will be hacking around in downstream, I'd would
> like to offer a warning. Whatever you do, do not ever add new calls to
> drmModeAtomicCommit or call anything that synchronously calls atomic
> commit or the legacy KMS functions. The architecture is designed around
> first collecting all the state an atomic commit needs, building the
> commit, testing it first, and if the test succeeds, only then firing
> the real commit. So if you want to control some new property or you
> want to turn off a monitor or anything, you have to make that new thing
> part of the state machinery and let the state machinery commit it for
> you. Anything else will quickly spiral into an unfixable mess.
>
> It was a huge effort to get rid of the "immediate" libdrm KMS calls and
> replace them with the atomic state machine. I recall that temporary
> video mode switching and maybe even DPMS might still be not quite there
> yet, because their original internal API fit really badly into the
> atomic design.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181123/aef6f1d2/attachment.html>