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@xxxxxxxxx> wrote: >>>> On 8/4/2016 5:04 PM, Emil Velikov wrote: >>>>> On 4 August 2016 at 11:16, Sharma, Shashank >>>>> <shashank.sharma@xxxxxxxxx> >>>>> 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@xxxxxxxxxxxxxxxxxxxxx > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
