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