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

Sharma, Shashank shashank.sharma at intel.com
Fri Aug 5 03:37:13 UTC 2016


Regards

Shashank


On 8/4/2016 9:39 PM, Daniel Vetter 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.
> -Daniel
Thanks Daniel, you explained the zest of this series better than me :)

Regards
Shashank


More information about the dri-devel mailing list