| Summary: | Linux 4.10 and newer limit pixel clock to 165 MHz on Haswell-ULT laptop | ||||||
|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Michael Hanselmann (hansmi) <public> | ||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
| Severity: | normal | ||||||
| Priority: | medium | CC: | intel-gfx-bugs | ||||
| Version: | unspecified | ||||||
| Hardware: | x86-64 (AMD64) | ||||||
| OS: | Linux (All) | ||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||
| i915 platform: | HSW | i915 features: | display/Other | ||||
| Attachments: |
|
||||||
|
Description
Michael Hanselmann (hansmi)
2019-09-03 22:10:18 UTC
There is clearly a dual-mode adaptor in the chain somewhere: [ 1428.752898] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode HDMI ID: DP-HDMI ADAPTOR\004 (err 0) [ 1428.753676] [drm:drm_dp_dual_mode_detect [drm_kms_helper]] DP dual mode adaptor ID: ff (err 0) [ 1428.753728] [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 1 HDMI) detected (max TMDS clock: 165000 kHz) Is the connector on the laptop a DP/mini-DP or HDMI? (In reply to Ville Syrjala from comment #1) > Is the connector on the laptop a DP/mini-DP or HDMI? The electrical connector is an HDMI Type A, as is the connector on the monitor. Would you like me to open the device to check whether there's any converter chip from DP to HDMI in the signal path (the mainboard pictures I found online were all of insufficient clarity)? (In reply to Michael Hanselmann (hansmi) from comment #2) > (In reply to Ville Syrjala from comment #1) > > Is the connector on the laptop a DP/mini-DP or HDMI? > > The electrical connector is an HDMI Type A, as is the connector on the > monitor. > > Would you like me to open the device to check whether there's any converter > chip from DP to HDMI in the signal path (the mainboard pictures I found > online were all of insufficient clarity)? Nah. It's clearly there since we can talk to it. So yeah, basically that means that you're trying to drive it out of spec, or the manufacturer messed up and used a dual-mode chip that misreports its maximum TMDS clock. We have to err on the side of caution and filter out modes that look out of spec, doing otherwise would lead to some poor chap getting a black screen. However if you want you can still keep driving it out of spec with the custom modeline. I guess the question is how would you add one under whatever wayland compositor you use. (In reply to Ville Syrjala from comment #3) > We have to err on the side of caution and filter out > modes that look out of spec, doing otherwise would lead to some poor chap > getting a black screen. I can only agree with you. Thank you for your quick assessment! > However if you want you can still keep driving it out of spec with the > custom modeline. I guess the question is how would you add one under > whatever wayland compositor you use. It's Gnome with Mutter. I'll investigate and follow-up for any future readers. (In reply to Michael Hanselmann (hansmi) from comment #4) > It's Gnome with Mutter. I'll investigate and follow-up for any future > readers. It appears as if Mutter doesn't allow for custom modelines and passes the kernel's modelines through. I've tried the following kernel command line parameters: video=2560x1440MR@59 video=HDMI-A-2:2560x1440R Unfortunately the pixel clock is still limited to 165 MHz. Ville, is there a way I can force a mode via parameters? (In reply to Michael Hanselmann (hansmi) from comment #5) > (In reply to Michael Hanselmann (hansmi) from comment #4) > > It's Gnome with Mutter. I'll investigate and follow-up for any future > > readers. > > It appears as if Mutter doesn't allow for custom modelines and passes the > kernel's modelines through. I've tried the following kernel command line > parameters: > > video=2560x1440MR@59 > video=HDMI-A-2:2560x1440R > > Unfortunately the pixel clock is still limited to 165 MHz. > > Ville, is there a way I can force a mode via parameters? Nope. Looks like the cmdline mode is treated the same as mode coming from the EDID, ie. is subject to getting filtered out from the connector's mode list. (In reply to Ville Syrjala from comment #6) > Nope. Looks like the cmdline mode is treated the same as mode coming from > the EDID, ie. is subject to getting filtered out from the connector's mode > list. That filtering is indeed the case. None of my other attempts like writing to the adapter and EDID via I²C worked (either the transactions were NACKed or outright ignored). As I'd rather not maintain my own kernel build I ended up writing a custom kernel module using Kernel probes to override the return value from "drm_dp_dual_mode_detect": https://github.com/hansmi/fake-dp-dual-mode Now, this is obviously a hack, but it's fine for myself. I'd be able to submit a kernel patch to add a parameter overriding the automatic detection. Do you think that'd be worth it? -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/393. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.