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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
