[Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags

[Emil Velikov]

On 4 August 2016 at 17:09, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Thu, Aug 04, 2016 at 03:31:45PM +0100, Emil Velikov wrote:
>> On 4 August 2016 at 14:15, Sharma, Shashank <shashank.sharma at intel.com> wrote:
>> > On 8/4/2016 5:04 PM, Emil Velikov wrote:
>> >>
>> >> On 4 August 2016 at 11:16, Sharma, Shashank <shashank.sharma at intel.com>
>> >> wrote:
>> >>>
>> >>> Hello Emil,
>> >>>
>> >>> Thanks for your time.
>> >>>
>> >>> I have got mixed opinion on this.
>> >>>
>> >>> IMHO we should expose them to userspace too, as UI agents like Hardware
>> >>> composer/X/Wayland must know what does these
>> >>>
>> >>> flags means, so that they can display them on the end user screen (like
>> >>> settings menu)
>> >>>
>> >>> But few people even think thats its too complex to be exposed to
>> >>> userspace
>> >>> agents.
>> >>>
>> >> If we want these/such flags passed between kernel and user space one must:
>> >>   - Provide a kernel interface how to do that
>> >>   - Provide a userspace (acked by respective developers/maintainers)
>> >> that the approach is sane and proves useful.
>> >>
>> >> Since the above can take some time, I'd suggest dropping those from
>> >> the UAPI header(s)... for now.
>> >>
>> >> -Emil
>> >
>> > Please guide me a bit more on this problem, Emil, Daniel.
>> > The reason why I want to pass this to userspace is, so that, HWC/X/any other
>> > UI manager, can send a modeset
>> > which is accurate upto aspect ratio.
>> >
>> Nobody(?) is arguing that you don't to pass such information to/from
>> userspace :-)
>> Your series does the internal parsing/management of the attribute and
>> has no actual UAPI implementation and/or userspace references (to
>> code/discussions). Thus the UAPI changes should _not_ be part of these
>> patches.
>>
>> Daniel's blog [1] has many educational materials why and how things
>> are done upstream. I would kindly invite you to give them (another?)
>> courtesy read.
>
> It reuses the already existing uapi mode structure. And since it extends
> them both on the probe side and on the modeset set this means userspace
> can just pass through the right probed mode and it'll all magically work.
> At least that's the idea.
>
> Now if you actually care about the different bits then you can select the
> right mode, but that's about it. So if you want to compensate for the
> non-square pixels in rendering then you need to look at it, but otherwise
> it's just a case of select the mode you want. I don't see what new
> userspace we'd need for that really, current one should all work nicely
> as-is. At least the entire point of doing this was seamless support with
> existing userspace.
I failed to click that drm_mode_convert_umode does input validation,
apart from the actual conversion.

Thanks a lot gents and sorry for the noise.
Emil