question about drm backend

[Pekka Paalanen]

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 --------------
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/20181120/7425ca59/attachment.sig>