[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Daniel Vetter]

On Tue, Nov 15, 2016 at 03:36:02PM +0530, Sharma, Shashank wrote:
> On 11/15/2016 3:30 PM, Daniel Vetter wrote:
> > On Tue, Nov 15, 2016 at 02:30:47PM +0530, Sharma, Shashank wrote:
> > > On 11/15/2016 2:21 PM, Daniel Vetter wrote:
> > > > On Mon, Nov 14, 2016 at 10:26:08PM +0530, Sharma, Shashank wrote:
> > > > > In any case, I guess addition of a cap for aspect ratio should fix the
> > > > > current objections for this implementation.
> > > > > 
> > > > > And I will keep it 0 by default, so that no aspect ratio information is
> > > > > added until userspace sets the cap to 1 on its own.
> > > > Note that cap = needs new userspace.
> > > > -Daniel
> > > I guess you mean a new libdrm, so yes, I will add this new cap in libdrm.
> > > Is that what you mean ?
> > Full stack solution, including enabling in an Xorg driver (or somewhere
> > else, we also have drm_hwcomposer as an option).
> > 
> > And because that's probably going to take forever I'm leaning towards
> > revert again. Ville?
> Not really, with a kernel cap implementation, the code will be as it was
> before this patch series ( as good as revert )
> And then when we want to enable it, we can add the corresponding Xserver
> patch.
> 
> I guess the current problem is if is breaks something in some userspace, but
> if I am loading the flags only when the cap is set, we should be good.

This is not how new uabi gets merged, see:

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements

Userspace must be ready, or it will not land. The entire point of my
suggestion to just extend the display modes was to avoid the need for
userspace, but since existing userspace tries to be too clever already,
that didn't work out.
Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch