[PATCH v17 03/14] compositor-drm: Don't set fb->size for non-dumb buffers

[Pekka Paalanen]

On Mon,  9 Jul 2018 14:23:09 +0100
Daniel Stone <daniels at collabora.com> wrote:

> When creating a drm_fb from client (wl_buffer/dmabuf), gbm_surface, or
> client buffers, set fb->size to 0. The size member is only used for dumb
> buffers, where we mmap the whole buffer, and need the size recorded to
> later pass to munmap.
> 
> Determining the full size of multi-planar buffers is difficult, as
> auxiliary planes are not guaranteed to have a (height*stride)
> allocation, e.g. if they are subsampled or if they do not contain pixel
> data at all but, e.g., compression information. Single-plane tiled
> buffers also often pad the buffer allocation to a multiple of tile
> height, making our existing calculation incorrect.
> 
> Though it does no harm to record incorrect information, it also does
> no good as we never use it; remove it in order to avoid any confusion.
> 
> Signed-off-by: Daniel Stone <daniels at collabora.com>
> ---
>  libweston/compositor-drm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 7753dfba6..29fa98da6 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -1063,7 +1063,7 @@ drm_fb_get_from_bo(struct gbm_bo *bo, struct drm_backend *backend,
>  	fb->handles[0] = gbm_bo_get_handle(bo).u32;
>  	fb->format = pixel_format_get_info(gbm_bo_get_format(bo));
>  	fb->modifier = DRM_FORMAT_MOD_INVALID;
> -	fb->size = fb->strides[0] * fb->height;
> +	fb->size = 0;
>  	fb->fd = backend->drm.fd;
>  
>  	if (!fb->format) {

Reviewed-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>


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/20180709/bcc20f42/attachment.sig>