[Intel-gfx] [PATCH 1/4] drm: add picture aspect ratio flags
Jose Abreu
Jose.Abreu at synopsys.com
Tue Aug 9 13:12:47 UTC 2016
Hi Sharma,
On 05-08-2016 04:37, Sharma, Shashank wrote:
> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Will you send a new version of these patches? I have a patch
ready that adds the new HDMI 2.0 modes to the CEA modes list in
DRM but these modes require the addition of the new picture
aspect ratio flags (64:27, 256:135). I can either wait that your
patches get accepted or I can add to my patch set one that adds
the new PAR flags.
Best regards,
Jose Miguel Abreu
More information about the dri-devel
mailing list