question about drm backend

[zou lan]

Hi pekka

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
and drm backend may increase the merge effort.

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?
Will AGL adopt the weston 5.0 or other weston version in their new AGL
version sunch as AGL 7.0?

Thank you!

Best Regards
Nancy

Pekka Paalanen <ppaalanen at gmail.com> 于2018年11月20日周二 下午7:28写道：

> On Tue, 20 Nov 2018 17:37:34 +0800
> zou lan <nancy.lan.zou at gmail.com> wrote:
>
> > Hi pekka
> >
> > Thank you for your reply. I have other questions about drm backend.
> >  I find weston 5.0 modify so much about drm backend and the interfaces of
> > compositor communicate with drm backend.
> > Is there any documents about the drm backend design?
>
> Hi Nancy
>
> Mostly no. The compositor/backend interface is a purely internal
> libweston detail, with the exception of compositor-drm.h which is
> libweston public API.
>
> We do try to add API docs in the form of doxygen comments to at least
> all new functions.
>
> > Why compositor need to add a structure weston_head? Is weston_output not
> > enough? why not let drm backend to judge whether to do
> > repaint/repaint_flush/repaint_cancel to keep libweston separate from drm
> > backend?
>
> There actually is a design doc for the head API (which is public
> libweston API, not just a backend detail), but it is unfortunately
> unreadable atm. while Phabricator is broken. I've been meant to migrate
> that content but haven't had a chance yet:
> https://gitlab.freedesktop.org/wayland/weston/issues/25
>
> In a crude summary, weston_head represents a connector while
> weston_output represents a CRTC. Heads were added to support hardware
> clone mode, where the same CRTC is feeding two or more connectors. That
> is, weston_output provides the content for more than one weston_head.
>
> Heads are exposed in the libweston public API, because the display
> configuration must be controlled by the compositor, not guessed by
> libweston. E.g. there are use cases where hardware clone mode must be
> used explicitly, and falling back to something else is not acceptable.
>
> While the Phabricator document is unavailable, you can read more
> rationale and details in the git history: git log -Sweston_head
> and 01f60211b2ff3d12bd8bc6a008ba07c30a666760 in particular.
>
> repaint_begin/repaint_flush/repaint_cancel is a general concept
> required by atomic KMS. Weston core manages the output timings and the
> surface state and protocol implications from repaints, and
> special-casing the repaint coalescing to the DRM backend would have
> been more complicated than this. We want to get as many repaints into a
> single atomic commit as possible, and modesets during CRTC
> reconfiguration may even require it for succeeding at all.
>
> Granted, the DRM-backend is the primary backend of libweston, so we
> tend to adapt the core infrastructure to cater for the DRM-backend
> foremost while letting everything else work with some changes as well.
> E.g. the weston_output::assign_planes hook is only really used by the
> DRM-backend.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181120/d20b1a2d/attachment.html>