[PATCH] Add aspect-ratio support in wayland layer.
shashank.sharma at intel.com
Wed Sep 20 06:08:15 UTC 2017
Sorry for the delay in response, I was OOO. I had a quick syncup with
Ankit, where he told me about the discussions you guys had, over this
Please find my comments inline.
On 9/12/2017 2:49 PM, Pekka Paalanen wrote:
> 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.
> nice to meet you!
Thanks, same here.
> 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:
>>>> This is a four patch series, in which two patches are already
>>>> merged, and two are waiting for user space implementation.
>>> 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
These are some very valid points, and I agree to most of them. But
probably we should discus about little bit about the theory of aspect
ratio here. There are three variants of aspect ratios which affect the
screen display 1. Display aspect ratio (DAR): Its the ratio of physical
dimension of TV/monitor (width mm / height mm) 2. Storage aspect ratio
(SAR): Its the ratio of the pixels of the picture captured at the
source. For example, a 1920x1080 image, SAR would be 1920:1080 = 16:9 3.
Pixel aspect ratio (PAR): The aspect ratio of the pixels being displayed
on the monitor. So an image of resolution 1920x1080 (SAR 16:9) when
being displayed on a TV of (DAR 16:9) will have square pixels of (PAR
1:1). So from the definition, we can deduce that PAR = DAR/SAR While
sending the AVI info-frames from source to sink, the source set aspect
ratio field, and the monitor prepares itself accordingly. In fact, there
is a HDMI compliance certification test (7-27) which checks if the
selected aspect ratio is being reflected in AVI IF correctly. Now, there
are many widescreen TVs and gaming monitors available in market, where a
selected gaming app / media player / dvd player / set-top box would want
to show non-square pixels for: - widescreen effect / theater effect. -
gaming experience. - VR/AR and few other modern display/gaming
techniques. Also, HDMI 2.0 standard / CEA-861-F have introduced new
aspect ratios like 64:27 and 256:135 so that modern games / media
playback can utilize these monitors / displays well. So considering
these facts, I was thinking that it would be under utilizing the monitor
capabilities and it may restrict the experience if we don't consider the
desired widescreen intention of the compositor / app. But at the same
time, I might have pulled the stuff too early, and right now when we are
in the stabilization stage, I guess it would be good to add the feature
at the Weston layer, and defer this activity for later once we have
proper infrastructure in place. So I liked the suggestions where we add
this later as an extension for Set Top Box/Media/IVI usages. I have
asked Ankit to re-tune the patch series as per your suggestions, and
restrict aspect ratio feature into drm-compositor only. He will probably
publish it today. Please have a look into that. Regards Shashank
>> - 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
> What is it that makes these non-square pixel video modes desireable?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel