Created attachment 145258 [details] i915 log of attaching Dell U2715H to Linux 4.19 I've recently upgraded a laptop from Debian 9 (Stretch) which used Linux 4.9 to 10 (Buster) which is using Linux 4.19. For about two years I've successfully used a custom modeline to drive an external monitor at its native resolution: # 2560x1440 59.95 Hz (CVT 3.69M9-R) hsync: 88.79 kHz; pclk: 241.50 MHz Modeline "2560x1440R" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync The upgrade involved switching from X.Org to Wayland with KMS. The native resolution is no longer offered and the monitor is driven at 2048x1152 instead. The situation is obviously undesirable. I'm not sure whether I've been driving the hardware out of specs or whether I'm dealing with a bug. I managed to identify what appears to be the causing condition in "drivers/gpu/drm/i915/intel_hdmi.c:hdmi_port_clock_limit" and confirmed that the native resolution is automatically chosen after applying a minor patch (the same original code exists in Linux 5.2 so it's not specific to 4.19): --- --- ./drivers/gpu/drm/i915/intel_hdmi.c.orig 2019-09-03 23:43:19.679250829 +0200 +++ ./drivers/gpu/drm/i915/intel_hdmi.c 2019-09-03 23:43:47.223415491 +0200 @@ -1504,10 +1504,6 @@ struct intel_connector *connector = hdmi->attached_connector; const struct drm_display_info *info = &connector->base.display_info; - if (hdmi->dp_dual_mode.max_tmds_clock) - max_tmds_clock = min(max_tmds_clock, - hdmi->dp_dual_mode.max_tmds_clock); - if (info->max_tmds_clock) max_tmds_clock = min(max_tmds_clock, info->max_tmds_clock); --- "dp_dual_mode.max_tmds_clock" is set to 165 MHz by "drm_dp_dual_mode_max_tmds_clock". I'm attaching a kernel log. The condition I ended up removing was added in commit b1ba124d8e95 by Ville Syrjälä in May 2016 (<https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b1ba124d8e95>). Machine information from dmidecode: Toshiba Satellite Z30-A with Intel Core i7-4500U CPU @ 1.80GHz (Type 0, Family 6, Model 69, Stepping 1). Monitor information: Dell U2715H with a native resolution of 2560x1440, connected via a noname HDMI cable. Tests with another cable didn't bring an improvement. Kernel: 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 Excerpt from EDID: --- … Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm 2560 2608 2640 2720 hborder 0 1440 1443 1448 1481 vborder 0 +hsync -vsync VertFreq: 59 Hz, HorFreq: 88786 Hz … Monitor ranges (GTF): 56-86Hz V, 30-113kHz H, max dotclock 300MHz … ---
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.