On 2018-06-27 11:39 AM, Emil Velikov wrote:
> On 27 June 2018 at 09:40, Michel Dänzer wrote:
>> On 2018-06-26 07:11 PM, Emil Velikov wrote:
>>> On 26 June 2018 at 17:23, Michel Dänzer wrote:
On 2018-06-26 05:43 PM, Emil Velikov wrote:
> On 25 June 2018 at 22:45, Zuo, Jerry wrote:
>>
>>
>>
>> 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?
>>
>>
> I don't have much time to tinker with it, hopefully the following
> proposal will be clear enough. If not perhaps I'll get to in at some
> point.
I'm afraid it's still rather vague to me at least. Anyway, since this is
a (at least behavioural) regression in the 4.18 kernel cycle, it cannot
be solved with userspace changes, especially not any involving xserver.
A solution is needed for the final 4.18 release which works with current
userspace.
Taking a step back, it's not clear to me why the kernel change bisected
in the bug report makes a difference as to whether Xorg prunes the 60 Hz
4K modes or not. EDID is identical in both cases, right? So does the
kernel report a different clock for the modes now, or what exactly has
changed that is
