[PATCH v3] compositor-drm: Add the aspect ratio parsing support

[Pekka Paalanen]

On Thu, 9 Nov 2017 19:24:00 +0530
"Nautiyal, Ankit K" <ankit.k.nautiyal at intel.com> wrote:

> 
> On 11/3/2017 3:52 PM, Pekka Paalanen wrote:
> > (I fixed the subject line to contain v3.)
> >
> > On Mon, 16 Oct 2017 20:25:23 +0530
> > Nautiyal Ankit <ankit.k.nautiyal at intel.com> wrote:
> >  

> >> @@ -2376,6 +2424,7 @@ static struct drm_mode *
> >>   drm_output_add_mode(struct drm_output *output, const drmModeModeInfo *info)
> >>   {
> >>   	struct drm_mode *mode;
> >> +	struct drm_backend *b;
> >>   	uint64_t refresh;
> >>   
> >>   	mode = malloc(sizeof *mode);
> >> @@ -2402,7 +2451,12 @@ drm_output_add_mode(struct drm_output *output, const drmModeModeInfo *info)
> >>   
> >>   	if (info->type & DRM_MODE_TYPE_PREFERRED)
> >>   		mode->base.flags |= WL_OUTPUT_MODE_PREFERRED;
> >> -
> >> +	/* if drm supports aspect ratio, set aspect ratio in weston_mode */
> >> +	b = to_drm_backend(output->base.compositor);
> >> +	if (b->aspect_ratio_supported)
> >> +		drm_set_aspect_ratio(&mode->base, info);
> >> +	else
> >> +		mode->base.aspect_ratio = WESTON_MODE_PIC_AR_NONE;  
> > This looks a little odd.
> >
> > If the kernel supports aspect ratio, then we can assume that the kernel
> > sets the flags correctly and we can just copy them.
> >
> > But, if the kernel does not support aspect ratio, does it guarantee
> > that the bits used for aspect ratio are zero? I would assume it does,
> > in which case we can just copy them, we are guaranteed to get NONE.
> >
> > I would not expect the kernel to return garbage in those bits, so
> > please correct me if I'm wrong.
> >
> > Furthermore, if the kernel does not support the aspect ratio flags,
> > will it also never expose aspect ratio modes to user space? Or is it so
> > that old kernels would expose aspect ratio modes without knowing they
> > are aspect ratio modes? In that case, when the kernel does not support
> > aspect ratio modes, it would be wrong to mark the modes as PIC_AR_NONE,
> > because they could be anything, and we would need a PIC_AR_UNKNOWN
> > value for them.
> >
> > Which way do old kernels work?  
> 
> Before the aspect-ratio patches in drm:
> The aspect-ratio modes will be there in the list of modes, but the modes 
> will have aspect-ratio flag bits (19-22) set as 0.
> If the user-land sends a mode, with the aspect-bits sets, those bits 
> will be ignored.
> 
> So yes, you are right, we can do away with the check here, and set the 
> aspect ratio according to the bits received.

Ok, I expected so, but wanted to confirm. Very good.

> As you already know, there is currently aspect-ratio patch in review, 
> and I am working on the adding the
> aspect-ratio client cap, patch submission is due.
> After aspect-ratio patches in drm:
> 
>     If user-land sets drm Client for aspect ratio (supports aspect ratio):
>     1. The modes will be listed and aspect ratio flag bits will be set.
>     2. The mode given by user-land to be set will be parsed for the
>     aspect ratio flags.
>     If user-land does not set drm client cap for aspect-ratio:
>     1. The modes with aspect-ratio, will be pruned from the list of
>     modes for a given connector.
>     2. If user-land gives any mode to be set, the flags for the
>     aspect-ratio for the usermode will be discarded.

Perfect!


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/20171110/498a0bae/attachment.sig>