Currently we have not explicitly defined the behaviour when the width and height of the writeback framebuffer do not match the width and height of the attached CRTC.
Allow the driver to perform a scale operation to fit the content, so systems with scaling blocks in the writeback path can easily expose them. Failure remains an option for all the systems that don't have a scaler. Cropping would make less sense, as the region to crop is underspecified without some other properties to define an origin. Signed-off-by: Derek Foreman <[email protected]> --- I have a draft merge request against weston for this at: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/2071 drivers/gpu/drm/drm_writeback.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c index 4da5d6094721..735a3cdff79a 100644 --- a/drivers/gpu/drm/drm_writeback.c +++ b/drivers/gpu/drm/drm_writeback.c @@ -58,6 +58,9 @@ * framebuffer to be written by the writeback connector. This property is * similar to the FB_ID property on planes, but will always read as zero * and is not preserved across commits. + * If the width and height of the framebuffer do not match those of the + * attached CRTC, the driver may either fail or scale (not crop) the + * content to fit the framebuffer. * Userspace must set this property to an output buffer every time it * wishes the buffer to get filled. * -- 2.53.0
