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

Wed Sep 20 06:08:15 UTC 2017

Hello Pekka,

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 
topic.
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.
> Hi,
>
> 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:
>>>> 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.
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
> see.
>
> What is it that makes these non-square pixel video modes desireable?
>
>
> Thanks,
> pq
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170920/0552f7d4/attachment.html>