<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <p>Hello Pekka,<br> </p> 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. <br> Please find my comments inline. <br> <br> On 9/12/2017 2:49 PM, Pekka Paalanen wrote:<br> <blockquote cite="mid:20170912121954.4e1d5b37@eldfell" type="cite"> <pre wrap="">On Mon, 11 Sep 2017 14:36:13 +0530 "Sharma, Shashank" <a class="moz-txt-link-rfc2396E" href="mailto:shashank.sharma@intel.com"><shashank.sharma@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> Hi, nice to meet you! </pre> </blockquote> Thanks, same here. <br> <blockquote cite="mid:20170912121954.4e1d5b37@eldfell" type="cite"> <pre wrap=""> Please bear with my ignorance below. </pre> <blockquote type="cite"> <pre wrap="">On 9/8/2017 7:43 PM, Pekka Paalanen wrote: </pre> <blockquote type="cite"> <pre wrap="">On Wed, 6 Sep 2017 17:50:00 +0530 Nautiyal Ankit <a class="moz-txt-link-rfc2396E" href="mailto:ankit.k.nautiyal@intel.com"><ankit.k.nautiyal@intel.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">From: Ankit Nautiyal <a class="moz-txt-link-rfc2396E" href="mailto:ankit.k.nautiyal@intel.com"><ankit.k.nautiyal@intel.com></a> 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: <a class="moz-txt-link-freetext" href="https://patchwork.freedesktop.org/series/10850/">https://patchwork.freedesktop.org/series/10850/</a> This is a four patch series, in which two patches are already merged, and two are waiting for user space implementation. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">- 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. </pre> </blockquote> <pre wrap=""> 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.<meta http-equiv="Content-Type" content="text/html; charset=windows-1252"><style>  </style> 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. </pre></blockquote>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 <blockquote cite="mid:20170912121954.4e1d5b37@eldfell" type="cite"><blockquote type="cite"><pre wrap="">- 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 ? </pre></blockquote><pre wrap=""> 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 </pre> </blockquote> </body></html>