Bug 107585

Wow! I made patches to implement the behaviour I described, but only after doing so did I notice that the kernel sees a value of 0x0 in the HDMI max data rate field. After digging a little deeper, I found this commit[1], which probably explains the discrepancy, and closes the door on a fix involving the VBT, at least for hardware equivalent to my system's configuration.

As a last-ditch attempt to be friendlier to users, I'd propose at least making an educated guess about the maximum TMDS clockrate based on which generation of Intel Graphics chipset is driving the port.

[1] https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/commit/?id=5a17ee2c8f9013f5db852d27564b837f9f2c5a9f

Please try to reproduce the error using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.

Jani, any comments or need Ville here?

(In reply to Simon from comment #1)
> As a last-ditch attempt to be friendlier to users, I'd propose at least
> making an educated guess about the maximum TMDS clockrate based on which
> generation of Intel Graphics chipset is driving the port.

It's not about the GPU, it's about the adapters. The user could plug in anything, and if we are unable to query it, the safe bet is to default to 165 MHz.

As I wrote in my email, for the benefit of others:
> With some adapters, we are unable to detect the adapter/sink max
> rate. If we incorrectly assume 300 MHz and it's really 165 MHz, the
> result is a black screen. If we incorrectly assume 165 MHz and it's
> really 300 MHz, the result is a picture on screen albeit with a worse
> resolution than the user wants.

From my POV, it's generally much more peaceful to deal with people whose bug is a degraded screen than with people whose bug is a black screen. ;)

Yeah, maybe in general the user can plug in random adaptors, but in this case the adaptor is internal, part of the laptop's mini-DisplayPort.

Sure, a black screen is suboptimal, but if someone is trying to use an old adapter to drive a 4K screen, they're going to need to replace the adaptor regardless of whether the result is a black screen or 1080p output. If they get a black screen, they can work around it by switching to a lower output mode, as long as the 4K output isn't the only display attached to the system. So for any laptop user the black screen isn't so severe, because the user can use the internal screen to pick a different mode. I'd guess that desktop users generally would have an HDMI port they can use instead of a passive connection via DisplayPort.

Meanwhile, in the case of TMDS underclocking, there's no direct clue that something is wrong, and almost no workaround. There were no clues in the kernel log without debugging enabled, and I couldn't figure out a workaround without running a working kernel and copying the modelinr out. For many people, the workaround would be to go back to Windows or OS X and just conclude that Linux has inferior hardware support. Is there any way we can figure out how the Windows driver is managing to do the right thing in this case?

(In reply to Simon from comment #4)
> Yeah, maybe in general the user can plug in random adaptors, but in this
> case the adaptor is internal, part of the laptop's mini-DisplayPort.

If you stick the cable to a Dual Mode (DP++) port, the logic is in the cable. Or in a dongle you stick between the DP++ port and a regular HDMI cable.

https://vesa.org/featured-articles/vesa-introduces-updated-dual-mode-standard-for-higher-resolution-interoperability-with-hdmi-displays/

Please keep the communication on the bug, thanks.

On Thu, 16 Aug 2018, Simon Ruggier <simon80@gmail.com> wrote:
> Should I bother booting with drm-tip? I never attached a dmesg from
> 4.18, so it's missing either way, but from your responses, I'm
> guessing there's nothing in drm-tip that fixes this.

I don't recall any fixes between v4.18 and drm-tip that would address
this. It might prove useful to attach the dmesg. But based on the
snippets you've included so far it looks like you have a type 1 dual
mode adaptor, and we limit it to 165 MHz.

IIUC whether clocks higher than 165 MHz work on type 1 adapters is pure luck, and depend on the electrical characteristics of the adapter and the cable. Since they were designed with max 165 MHz in mind, all bets are off.

Ah, OK, I had assumed that the cable was fully passive, but if these register values are coming from the cable, then yes, my position is becoming more and more tenuous. What is the Windows driver doing, then? I guess it's just taking risks?

It would be nice if there was an override for this situation that was easier than manually adding a mode via xrandr, but admittedly, it's a tradeoff there for some users, and I can no longer argue that it's a bug at this point, more of a feature request.

If there's anything you're willing to change to improve the situation (in a "patches welcome" sort of way), please reopen the bug. If you're resolved to stick with the status quo, then we might as well resolve this as not a bug.

Please post your full dmesg with drm.debug=14 in case we've overlooked something.

Created attachment 141275 [details]
dmesg-4.18.0-7de4aa318074

This dmesg output is from a kernel built from commit 437b1c598624454e36690c1c56ce1a27e2ed7893.

Jani, do we need any other info from Simon for this issue?

I think our conclusion is wontfix. Thanks for the report.