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: commit 55d7f30ee1096474cb5bdbca46b60f23ce8b1f83 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. Thank you. 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 git://github.com/vsyrjala/linux.git dp_dual_mode_type2_broken
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 > 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) > ... Ah. So my VBT heuristic is the problem here. Please attach a copy of /sys/kernel/debug/dri/0/i915_opregion
Created attachment 126959 [details] /sys/kernel/debug/dri/0/i915_opregion 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) Power management Hotplug signaling HDMI output Content protection High speel link TMDS/DVI signaling DisplayPort output Digital output 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. commit 7a17995a3dc8613f778a9e2fd20e870f17789544 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> 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. commit 12b70ec0d3a6eb2696f3c091af6ecac31d2f8e66 Merge: 6238986 c2ee69d Author: Linus Torvalds <torvalds@linux-foundation.org> AuthorDate: Fri Nov 18 08:22:48 2016 -0800 Commit: Linus Torvalds <torvalds@linux-foundation.org> CommitDate: Fri Nov 18 08:22:48 2016 -0800
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.