On 2018-06-26 07:11 PM, Emil Velikov wrote: > On 26 June 2018 at 17:23, Michel Dänzer <mic...@daenzer.net> wrote: >> On 2018-06-26 05:43 PM, Emil Velikov wrote: >>> On 25 June 2018 at 22:45, Zuo, Jerry <jerry....@amd.com> wrote: >>>> Hello all: >>>> >>>> >>>> >>>> We are working on an issue affecting 4K@60 HDMI display not to light up, >>>> but >>>> only showing up 4K@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@60 supported. Such HDMI 4K@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@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@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@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@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. >> > Might have been too brief there. Here goes a more elaborate > suggestion, please point out any misunderstandings. > > If we look into the drivers we'll see a call to xf86InterpretEDID(), > followed by xf86OutputSetEDID(). > The former doing a partial parsing of the edid, creating a xf86MonPtr > (timings information et al.) with the latter attaching it to the > output. > > Thus as we get into xf86ProbeOutputModes/xf86ValidateModesClocks the > Xserver probes the mode against given timing/bandwidth constrains, > discarding it where applicable. > > Considering that the DRM driver already does similar checks, X could > side-step the parsing and filtering/validation all together. > Trusting the kernel should be reasonable, considering weston (and I > would imagine other wayland compositors) already do so.
It's still not clear to me what exactly you're proposing. Maybe you can whip up at least a mock-up patch? > Obviously, manually added modelines (via a config file) would still > need to be validated. How would that be done? Does the kernel provide functionality for this? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel