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 <[email protected]> wrote: > On 2018-06-26 05:43 PM, Emil Velikov wrote: > > Hi Jerry, > > > > On 25 June 2018 at 22:45, Zuo, Jerry <[email protected]> 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. > > > -- > Earthling Michel Dänzer | http://www.amd.com > Libre software enthusiast | Mesa and X developer > _______________________________________________ > [email protected]: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
