<div dir="ltr">Hi pekka<div><br></div><div>Thank you so much to explain the drm backend details. I ask these because some company may implement their own drm backend, changes on interfaces between libweston</div><div>and drm backend may increase the merge effort.</div><div><br></div><div>Could I also ask is weston backward compatible from weston 2.0 to weston 5.0 from users. According to my study, I think there is no big impacts for users, is it right?</div><div>Will AGL adopt the weston 5.0 or other weston version in their new AGL version sunch as AGL 7.0?</div><div><br></div><div>Thank you!</div><div><br></div><div>Best Regards</div><div>Nancy </div></div><br><div class="gmail_quote"><div dir="ltr">Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> 于2018年11月20日周二 下午7:28写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, 20 Nov 2018 17:37:34 +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>
> Thank you for your reply. I have other questions about drm backend.<br>
>  I find weston 5.0 modify so much about drm backend and the interfaces of<br>
> compositor communicate with drm backend.<br>
> Is there any documents about the drm backend design?<br>
<br>
Hi Nancy<br>
<br>
Mostly no. The compositor/backend interface is a purely internal<br>
libweston detail, with the exception of compositor-drm.h which is<br>
libweston public API.<br>
<br>
We do try to add API docs in the form of doxygen comments to at least<br>
all new functions.<br>
<br>
> Why compositor need to add a structure weston_head? Is weston_output not<br>
> enough? why not let drm backend to judge whether to do<br>
> repaint/repaint_flush/repaint_cancel to keep libweston separate from drm<br>
> backend?<br>
<br>
There actually is a design doc for the head API (which is public<br>
libweston API, not just a backend detail), but it is unfortunately<br>
unreadable atm. while Phabricator is broken. I've been meant to migrate<br>
that content but haven't had a chance yet:<br>
<a href="https://gitlab.freedesktop.org/wayland/weston/issues/25" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/wayland/weston/issues/25</a><br>
<br>
In a crude summary, weston_head represents a connector while<br>
weston_output represents a CRTC. Heads were added to support hardware<br>
clone mode, where the same CRTC is feeding two or more connectors. That<br>
is, weston_output provides the content for more than one weston_head.<br>
<br>
Heads are exposed in the libweston public API, because the display<br>
configuration must be controlled by the compositor, not guessed by<br>
libweston. E.g. there are use cases where hardware clone mode must be<br>
used explicitly, and falling back to something else is not acceptable.<br>
<br>
While the Phabricator document is unavailable, you can read more<br>
rationale and details in the git history: git log -Sweston_head<br>
and 01f60211b2ff3d12bd8bc6a008ba07c30a666760 in particular.<br>
<br>
repaint_begin/repaint_flush/repaint_cancel is a general concept<br>
required by atomic KMS. Weston core manages the output timings and the<br>
surface state and protocol implications from repaints, and<br>
special-casing the repaint coalescing to the DRM backend would have<br>
been more complicated than this. We want to get as many repaints into a<br>
single atomic commit as possible, and modesets during CRTC<br>
reconfiguration may even require it for succeeding at all.<br>
<br>
Granted, the DRM-backend is the primary backend of libweston, so we<br>
tend to adapt the core infrastructure to cater for the DRM-backend<br>
foremost while letting everything else work with some changes as well.<br>
E.g. the weston_output::assign_planes hook is only really used by the<br>
DRM-backend.<br>
<br>
<br>
Thanks,<br>
pq<br>
</blockquote></div>