Created attachment 126917 [details]
xrandr --verbose output on kernel 4.7
From kernel version 4.7 onwards, I lost the monitor native resolution of 2560x1080, which was automatically detected without any X configuration.
I bisected the culprit commit, and the chosen one was:
drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT
I don't know how to go any further by myself, but can follow almost any steps you give me to help diagnose the issue.
My config is:
-- system architecture: x86_64
-- kernel version: 4.7.5
-- Linux distribution: Arch Linux
-- Machine or mother board model:
- Motherboard: Asus B75M-PLUS
- CPU: Intel(R) Core(TM) i5-3470S
- GPU: Intel® HD Graphics 2500 (integrated)
- Monitor: LG(R) Ultrawide 21:9 29UM67-P
-- Display connector: HDMI
Created attachment 126918 [details]
xrandr --verbose output on kernel 4.6
Based on what I saw on irc (assuming this is the same case, or similar), it looks like a broken type 2 DP->HDMI adaptor is involved. Why anyone would solder such a thing to the motherboard I can't figure out. I'm assuming you'we connected the cable to a HDMI connector on the motherboard, and not a DP connector?
Anyways, please try this branch
Yes, between the monitor and the motherboard there's only a HDMI cable. I'm not aware of any kind of adaptor inside the motherboard, if that's of any help.
I just booted the freshly compiled "dp_dual_mode_type2_broken" branch (as of 02676478a756db9395df0eb8387c40c887fd450d) and the problem persists.
Enabling "drm.debug=0x4" in kernel comand line, I saw a line that may means more to you that it does to me:
[ 0.697620] [drm:intel_hdmi_set_edid [i915]] Assuming DP dual mode adaptor presence based on VBT
[ 0.697649] [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 1 DVI) detected (max TMDS clock: 165000 kHz)
[ 0.697785] [drm:drm_mode_debug_printmodeline [drm]] Modeline 52:"2560x1080" 60 185580 2560 2624 2688 2784 1080 1083 1093 1111 0x48 0xa
[ 0.697792] [drm:drm_mode_prune_invalid [drm]] Not using 2560x1080 mode: CLOCK_HIGH
I'll attach the complete kernel logs in case you need them.
Thanks for your time!
Created attachment 126928 [details]
dmesg dump of dp_dual_mode_type2_broken branch
(In reply to Daniel Otero from comment #3)
> Yes, between the monitor and the motherboard there's only a HDMI cable. I'm
> not aware of any kind of adaptor inside the motherboard, if that's of any
> I just booted the freshly compiled "dp_dual_mode_type2_broken" branch (as of
> 02676478a756db9395df0eb8387c40c887fd450d) and the problem persists.
> Enabling "drm.debug=0x4" in kernel comand line, I saw a line that may means
> more to you that it does to me:
> [ 0.697620] [drm:intel_hdmi_set_edid [i915]] Assuming DP dual mode
> adaptor presence based on VBT
> [ 0.697649] [drm:intel_hdmi_set_edid [i915]] DP dual mode adaptor (type 1
> DVI) detected (max TMDS clock: 165000 kHz)
Ah. So my VBT heuristic is the problem here. Please attach a copy of
Created attachment 126959 [details]
Sorry for the delay, I wasn't at home.
Updated as Highest+Blocker due to regression w/o workaround.
(In reply to Jari Tahvanainen from comment #7)
> Updated as Highest+Blocker due to regression w/o workaround.
Well, there is a workaround of sorts; that is add the mode back manually:
xrandr --newmode something 185.580 2560 2624 2688 2784 1080 1083 1093 1111 -hsync -vsync
xrandr --addmode HDMI2 something
xrandr --output HDMI2 --mode something
Looking at the VBT we see the port:
EFP device info:
Device handle: 0x0020 (EFP 3 (HDMI/DVI/DP))
Device type: 0x60d6 (DisplayPort/HDMI/DVI)
High speel link
So it clearly claims that the port is capable of DP output. Which is why we think that it's a DP++ port as opposed to a HDMI port.
It does claim to be an actual HDMI port in the actual port information:
Port: 0x03 (HDMI-D)
however we can't really trust that information since there are other machines out there that have ports claiming to be HDMI like this, but are in fact DP++ ports.
So at the moment I can't really see any way we can win :(
Created attachment 127590 [details] [review]
[PATCH] drm/i915: Assuming non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
This adjusts the heuristic a bit, and I think it should recover your missing mode. Please test.
I just applied the patch on the last stable release (4.8.5) and the resolution is back again!
I never would have thought that the fix would be this kind of "spot the differences" between various vendors bios.
So, thank you very much! ￼I appreciate your time!
Reference to Ville's fix: https://patchwork.freedesktop.org/series/15187/
waiting for upstream / merge to close it
(In reply to yann from comment #12)
> Reference to Ville's fix: https://patchwork.freedesktop.org/series/15187/
> waiting for upstream / merge to close it
Please don't mark bugs as fixed until the patch is actually in.
Author: Ville Syrjälä <firstname.lastname@example.org>
Date: Fri Nov 11 19:14:24 2016 +0200
drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT
Closing resolved+fixed. Verified by reporter.
Merge: 6238986 c2ee69d
Author: Linus Torvalds <email@example.com>
AuthorDate: Fri Nov 18 08:22:48 2016 -0800
Commit: Linus Torvalds <firstname.lastname@example.org>
CommitDate: Fri Nov 18 08:22:48 2016 -0800