On 4 August 2016 at 17:09, Daniel Vetter <daniel@xxxxxxxx> 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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
