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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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?

- Should we or should we not specify a VIC in the AVI infoframe
  when the userspace doesn't support aspect ratio flags?

  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.

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel