On Tue, 20 Nov 2018 17:37:34 +0800 zou lan <[email protected]> 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
pgpm4KPc6NG_n.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
