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

[Ville Syrjälä]

On Tue, Nov 15, 2016 at 08:40:01PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> On 11/15/2016 7:48 PM, Ville Syrjälä wrote:
> > On Tue, Nov 15, 2016 at 01:48:04PM +0000, Jose Abreu wrote:
> >> Hi,
> >>
> >>
> >>
> >> On 15-11-2016 10:52, Daniel Vetter wrote:
> >>> 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
> >> @Ville
> >>
> >> I gave my tested by to these patches because I was facing the
> >> same scenario as Shashank: HDMI compliance. I believe we need to
> >> find a better way to handle this instead of just reverting. The
> >> HDMI spec is evolving so we also need to evolve. Of course that
> >> if this is breaking user space then we can revert and wait until
> >> we figure the best way to implement this.
> >>
> >> Anyway, this is a wild guess but I think the reason you are
> >> loosing modes may be because of
> >> drm_mode_equal_no_clocks_no_stereo() which is always expecting a
> >> aspect ratio flag to be defined. If there isn't one defined then
> >> it will unconditionally return false, even if the modes are
> >> equal.
> > I am well aware why we're losing modes. One reason is the mode equal
> > checks in the kernel as you suspect, the other is simply userspace
> > rejecting everything with the aspect ratio defined.
> >
> >> Can you please test this patch and see if it fixes on your
> >> side? WARNING: Not compile tested
> > I already did something like that earlier, except I rewrote the
> > entire messy mode matching code to use a cleaner flag based approach:
> >
> > git://github.com/vsyrjala/linux.git cea_f_vics
> >
> > But that doesn't solve the userspace ABI issue, and there are still a
> > lot of unanswered questions like:
> >
> > - Should we define aspect ratios for modes not directly coming from
> >    edid_cea_modes[]?
> >
> >    I beleive the answer must be "yes" at least in the cases where the
> >    EDID lists the VIC even if we then skip adding the mode due to
> >    already having it on the list via from another source. Perhaps we
> >    want the aspect ratio even if the VIC wasn't directly specified?
> Wouldn't this break the whole concept of VIC, which is supposed to point 
> to a unique mode ?

Not sure what you're asking. We're already filtering out duplicates.

> > - Should we or should we not specify a VIC in the AVI infoframe
> >    when the userspace doesn't support aspect ratio flags?
> This is a requirement of HDMI compliance tests, if userspace 
> supports/handles aspect ratio, it should set cap, and it will be set in 
> kernel flags
> and we should load that in AV IF.  Are you planning to suggest a better 
> way, in which this can be done ?

I was asking for the case where userspace doesn't specify the aspect
ratio on account of not understanding what aspect ratios are.

> >    I would guess the answer is again "yes", and we should just pick the
> >    preferred aspect ratio for the mode. At least that's closer to what
> >    we've been doing up to now (except we just picked the first VIC, so
> >    we might have picked the non-preferred aspect ratio actually). At
> >    least having the VIC in the infoframe would seem like a safer option
> >    than not having it, in case there's some cheap ass hardware that
> >    can't do anything sensible without being hand fed a VIC.
> >
> > - How we should handle the aspect ratio in mode sorting?
> >
> >    I think we want some sensible sorting order for these. Preferred
> >    aspect ratio first would seem like the obvious choice. I do realize
> >    that we don't sort based on 3D stereo flags either, but I thinking we
> >    probably should.
> What is the need of this sorting ? None of the standards define/suggest 
> this. AFAIK, the requirement is that only the preferred mode should be 
> notified
> to the userspace, if a system has to take a call, it can create its 
> policy, if a user has to take a call, it can pick any from the list.

Dumb userspace will just pick the first mode it sees that sort of
matches what it wants. So we had better make sure that one has the more
sensible aspect ratio choice.

-- 
Ville Syrjälä
Intel OTC