4K at 60 YCbCr420 missing mode in usermode

[Mike Lothian]

Hi

I'm happy to test this when I get home

I'm currently reverting that patch that enables >8bit colour to get 60Hz
back

Cheers

Mike

On Tue, 26 Jun 2018 at 17:23 Michel Dänzer <michel at daenzer.net> wrote:

> On 2018-06-26 05:43 PM, Emil Velikov wrote:
> > Hi Jerry,
> >
> > On 25 June 2018 at 22:45, Zuo, Jerry <Jerry.Zuo at amd.com> wrote:
> >> Hello all:
> >>
> >>
> >>
> >> We are working on an issue affecting 4K at 60 HDMI display not to light
> up, but
> >> only showing up 4K at 30 from:
> >> https://bugs.freedesktop.org/show_bug.cgi?id=106959 and others.
> >>
> >>
> >>
> >> Some displays (e.g., ASUS PA328) HDMI port shows YCbCr420 CEA extension
> >> block with 4K at 60 supported. Such HDMI 4K at 60 is not real HDMI 2.0, but
> still
> >> following HDMI 1.4 spec. with maximum TMDS clock of 300MHz instead of
> >> 600MHz.
> >>
> >> To get such 4K at 60 supported, it needs to limit the bandwidth by
> reducing the
> >> color space to YCbCr420 only. We’ve already raised YCbCr420 only flag
> >> (attached patch) from kernel side to pass the mode validation, and
> expose it
> >> to user space.
> >>
> >>
> >>
> >>     We think that one of the issues that causes this problem is due to
> >> usermode pruning the 4K at 60 mode from the modelist (attached
> Xorg.0.log). It
> >> seems like when usermode receives all the modes, it doesn't take in
> account
> >> the 4K at 60 YCbCr4:2:0 specific mode. In order to pass validation of
> being
> >> added to usermode modelist, its pixel clk needs to be divided by 2 so
> that
> >> it won't exceed TMDS max physical pixel clk (300MHz). That might
> explain the
> >> difference in modes between our usermode and modeset.
> >>
> >>
> >>
> >>     Such YCbCr4:2:0 4K at 60 special mode is marked in DRM by raising a
> flag
> >> (y420_vdb_modes) inside connector's display_info which can be seen in
> >> do_y420vdb_modes(). Usermode could rely on that flag to pick up such
> mode
> >> and halve the required pclk to prevent such mode getting pruned out.
> >>
> >>
> >>
> >> We were hoping for someone helps to look at it from usermode
> perspective.
> >> Thanks a lot.
> >>
> > Just some observations, while going through some coffee. Take them
> > with a pinch of salt.
> >
> > Currently the kernel edid parser (in drm core) handles the
> > EXT_VIDEO_DATA_BLOCK_420 extended block.
> > Additionally, the kernel allows such modes only as the (per connector)
> > ycbcr_420_allowed bool is set by the driver.
> >
> > Quick look shows that it's only enabled by i915 on gen10 && geminilake
> hardware.
> >
> > At the same time, X does it's own fairly partial edid parsing and
> > doesn't handle any(?) extended blocks.
> >
> > One solution is to update the X parser, although it seems like a
> > endless game of cat and mouse.
> > IMHO a much better approach is to not use edid codepaths for KMS
> > drivers (where AMDGPU is one).
> > On those, the supported modes is advertised by the kernel module via
> > drmModeGetConnector.
>
> We are getting the modes from the kernel; the issue is they are then
> pruned (presumably by xf86ProbeOutputModes => xf86ValidateModesClocks)
> due to violating the clock limits, as described by Jerry above.
>
>
> --
> Earthling Michel Dänzer               |               http://www.amd.com
> Libre software enthusiast             |             Mesa and X developer
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20180626/25a18fbb/attachment-0001.html>