DRM Client capability for aspect ratio

Daniel Stone daniel at fooishbar.org
Thu Oct 19 15:47:59 UTC 2017


Hi Ankit,

On 17 October 2017 at 12:08, Nautiyal, Ankit K
<ankit.k.nautiyal at intel.com> wrote:
> On Similar lines, I was able to add the new DRM_CLIENT_CAP_ASPECT_RATIO. I
> also added a member 'aspect_ratio_required' in drm_file structure,

Quick bikeshed suggestion: aspect_ratio_supported. ;)

> Now what I want to do is
>
> 1.     Setting the aspect-ratio flag-bits (19-22) in drmModeModeInfo only if
> the client advertises that it requires the aspect-ratio.
>
> So I need to have this information (that client requires aspect ratio)
> available in the function:
>
> drm_mode_convert_to_umode( ) : Where the flag bits are actually set

This would be called in, e.g., drmModeGetCrtc.

> 2.     Similarly in case of modeset request from the client, we would want
> to parse the aspect ratio bits from the requested  drmModeModeInfo only if
> the client requires aspect ratio.
>
> This will require change in the function:
>
> drm_mode_convert_umode()  : Where the flag bits of  drm_mode_mode_info are
> read by the drm layer to determine the aspect ratio and set in
> drm_display_mode)

As in drmModeSetCrtc, or when doing an atomic modeset, pulling the
mode from the blob identified by MODE_ID.

> The problem is that, both these functions have drm_mode_mode_info and
> drm_display_mode as the only arguments, but our flag aspect_ratio_required
> is in file_priv (struct drm_file).
>
> To do this there are two ways I can think of:
>
> 1.     Change the drm_mode_convert_umode() to include aspect_ratio_required
> flag.
>
>         Before calling this function, the file_priv->aspect_ratio_required
> will be checked and the flag will be set accordingly.
>
> 2.     While getting the drmClientCap from client, instead of storing this
> information in file-priv, store this info in some other structure.

I think you could just pass the file_priv directly; it seems a bit more clear.

One case I think you're missing though, is where a client discovers an
existing MODE_ID blob (via the atomic property), then gets the blob
contents to parse. In this case, we might pass the client unsupported
flags. I don't have a really good suggestion for fixing this, apart
from duplicating the blob content and returning a different result to
userspace ... !

Cheers,
Daniel


More information about the dri-devel mailing list