[PATCH] Add aspect-ratio support in wayland layer.

[Pekka Paalanen]

On Mon, 11 Sep 2017 14:36:13 +0530
"Sharma, Shashank" <shashank.sharma at intel.com> wrote:

> Hello Pekka
> 
> Thanks for your review comments and constructive discussions with Ankit 
> on IRC.
> I am Shashank from Intel, I am guiding Ankit on this activity.  I have 
> few comments (inline),
> it would be great if you can let us know your view on this.

Hi,

nice to meet you!

Please bear with my ignorance below.

> On 9/8/2017 7:43 PM, Pekka Paalanen wrote:
> > On Wed,  6 Sep 2017 17:50:00 +0530
> > Nautiyal Ankit <ankit.k.nautiyal at intel.com> wrote:
> >  
> >> From: Ankit Nautiyal <ankit.k.nautiyal at intel.com>
> >>
> >> This patch series adds video mode aspect ratio support for
> >> wayland protocol and weston drm compositor. This patch series
> >> adds two patches:
> >> 1- Adds aspect ratio flag bits bits in wl_output_mode flags
> >> as per DRM layer implementation.
> >> 2- Preserves and uses the aspect ratio flags while selecting
> >> the mode for modeset in weston drm compositor.
> >>
> >> The corresponding kernel implementation for the aspect ratio support
> >> in DRM Layer can be found here:
> >> https://patchwork.freedesktop.org/series/10850/
> >>
> >> This is a four patch series, in which two patches are already
> >> merged, and two are waiting for user space implementation.  
> > Hi,
> >
> > we discussed these patches on #wayland in IRC, and I believe we came to
> > the following conclusion:
> >
> > - Let's not add to wayland.xml, and not advertise the aspect ratio to
> >    clients. There is no need to do this, and clients are currently not
> >    able to take advantage of it either.  
> - In this case, how to decide what should be the aspect ratio of the 
> output mode and based on what ?
>    For example If a CEA mode is available for 16:9 and 4:3 aspects, 
> which one to pick and how ? If we don't
>    get inputs from the client, we would be picking the first mode in the 
> list which might not be the best practice.

Clients have no part in picking the video mode in general. Like I said,
there is no standard Wayland protocol to tell the compositor to pick
a video mode at this time.

I'm also starting to think that exposing the list of possible video
modes was not well thought through and would have been better omitted
completely. It already breaks apart on nested compositors where instead
of a few discrete modes one can pick freely from a range of widths and
heights, for instance.

The policy and configuration to choose the appropriate video mode lies
with each compositor. In Weston's case those are weston.ini for
configuration and the DRM-backend has the policy. Weston's policy is
simple and probably inadequate as it is. The way to fix that is to
patch Weston.

How to pick the right mode is a question that has no answer without a
specific use case and the environment. I envision moving the policy
from the DRM-backend to the users of libweston (into e.g. Weston) in
the future.

For example for a desktop, I struggle to imagine why anyone would want
to pick a video mode with non-square pixels. All generic software
assumes pixels are square. I would assume that also display panels are
built with square pixels, no?

For TV and such uses, I know nothing at all except for the feeling that
the video standards are still crippled by the designs from the 1960s.

If a compositor is being used for a special, non-desktop purpose, I
would also imagine it encodes its own configuration and policy for
choosing video modes. The choice requires case specific knowledge.
Clients could also be involved via domain specific Wayland protocol
extensions.

> - While supporting advance display outputs like HDMI 2.0 / UHD, when the 
> content can be in super wide aspect
>     like 64:27 for movies/game, wouldn't it be under utilization of 
> display capabilities not to pick it ?

I'm afraid you will need to explain those use cases in much more detail
before I could make any comment on what is better or suggest a solution.

My naive thinking is, if a desktop compositor chooses a video mode with
non-square pixels, then it needs to scale all application content such
that applications will effectively have square pixels since that is
what they expect. I assume reality is different, but I have no
knowledge of it.

If display panels are manufactured with square pixels anyway, the above
configuration would result in scaling twice for no benefit that I can
see.

What is it that makes these non-square pixel video modes desireable?


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/20170912/d5d65811/attachment.sig>