| Summary: | Sometimes does not detect 60Hz Full HD mode for external display, switching to 60 Hz with interlace | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Martin Steigerwald <Martin> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED WORKSFORME | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | intel-gfx-bugs, ville.syrjala |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| See Also: | https://bugs.freedesktop.org/show_bug.cgi?id=102614 | ||
| Whiteboard: | |||
| i915 platform: | SNB | i915 features: | display/DP |
| Attachments: | |||
|
Description
Martin Steigerwald
2018-02-04 11:15:05 UTC
Hmmm, X.org is using modesetting driver, so I likely put it into the wrong category. Sorry. I see no modesetting component for DRI, so… not sure where to assign it. Please reassign. First of all. Sorry about spam. This is mass update for our bugs. Sorry if you feel this annoying but with this trying to understand if bug still valid or not. If bug investigation still in progress, please ignore this and I apologize! If you think this is not anymore valid, please comment to the bug that can be closed. If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug. (In reply to Jani Saarinen from comment #2) > First of all. Sorry about spam. > This is mass update for our bugs. > > Sorry if you feel this annoying but with this trying to understand if bug > still valid or not. As of 4.16-rc6 this bug is still valid. I found a work-around. When I move the DisplayPort cable from DP2 to DP3 or wise versa *while* the session is running, the 60 Hz resolution is always detected and I can activate it again. What can also happen that one Plasma session gets is right and when I open up another Plasma session via SDDM in the other one only the interlaced mode is detected. So the one session has the 60 Hz resolution, while the other just has the interlaced one, yet still with the same cable and at the same time (minus delay for switching between sessions via Ctrl-Alt-F7/8). I tried with four cables already. However, I have a cable where this appeared more rarely (no scientific measurement, just personal impression). Curiously it was the longest one with 5 meters. So I ordered another cable like this, but just 2 meters and will test it as well. Since for a long time with previous kernels I did not see this issue and since the issue always goes away when moving the Displayport cable between DP2 and DP3, I still think that it is not or at least not solely a cabling issue. Please add drm.debug=14 module parameter, and attach dmesg from boot to reproducing the problem. Thanks. (In reply to Jani Nikula from comment #4) > Please add drm.debug=14 module parameter, and attach dmesg from boot to > reproducing the problem. Thanks. I booted with that module parameter and it appears that the driver detects the mode but thinks its clock would be too high: Apr 7 12:38:52 merkaba kernel: [ 6.825185] [drm:drm_mode_debug_printmodeline [drm]] Modeline 74:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 Apr 7 12:38:52 merkaba kernel: [ 6.825189] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH Apr 7 12:38:52 merkaba kernel: [ 6.825194] [drm:drm_mode_debug_printmodeline [drm]] Modeline 107:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 Apr 7 12:38:52 merkaba kernel: [ 6.825198] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH Apr 7 12:38:52 merkaba kernel: [ 6.825203] [drm:drm_mode_debug_printmodeline [drm]] Modeline 76:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1089 1095 1125 0x40 0xa Apr 7 12:38:52 merkaba kernel: [ 6.825207] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH Apr 7 12:38:52 merkaba kernel: [ 6.825211] [drm:drm_mode_debug_printmodeline [drm]] Modeline 93:"1920x1080" 0 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 Apr 7 12:38:52 merkaba kernel: [ 6.825215] [drm:drm_mode_prune_invalid [drm]] Not using 1920x1080 mode: CLOCK_HIGH Apr 7 12:38:52 merkaba kernel: [ 6.825219] [drm:drm_mode_debug_printmodeline [drm]] Modeline 80:"1680x1050" 0 146250 1680 1784 1960 2240 1050 1053 1059 1089 0x40 0x6 Apr 7 12:38:52 merkaba kernel: [ 6.825223] [drm:drm_mode_prune_invalid [drm]] Not using 1680x1050 mode: CLOCK_HIGH However when I do the plug the displayport cable to the other port trick it again accepted the 70 Hz mode: Apr 7 12:42:15 merkaba kernel: [ 210.505175] [drm:drm_mode_debug_printmodeline [drm]] Modeline 79:"1920x1080" 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 Apr 7 12:42:15 merkaba kernel: [ 210.505183] [drm:drm_mode_debug_printmodeline [drm]] Modeline 115:"1920x1080" 60 148352 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 Apr 7 12:42:15 merkaba kernel: [ 210.505190] [drm:drm_mode_debug_printmodeline [drm]] Modeline 102:"1920x1080i" 60 74250 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Apr 7 12:42:15 merkaba kernel: [ 210.505197] [drm:drm_mode_debug_printmodeline [drm]] Modeline 120:"1920x1080i" 60 74176 1920 2008 2052 2200 1080 1084 1094 1125 0x40 0x15 Apr 7 12:42:15 merkaba kernel: [ 210.505204] [drm:drm_mode_debug_printmodeline [drm]] Modeline 82:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1089 1095 1125 0x40 0xa Apr 7 12:42:15 merkaba kernel: [ 210.505212] [drm:drm_mode_debug_printmodeline [drm]] Modeline 101:"1920x1080" 50 148500 1920 2448 2492 2640 1080 1084 1089 1125 0x40 0x5 Apr 7 12:42:15 merkaba kernel: [ 210.505219] [drm:drm_mode_debug_printmodeline [drm]] Modeline 103:"1920x1080i" 50 74250 1920 2448 2492 2640 1080 1084 1094 1125 0x40 0x15 I will attach two kern.log files, one with a boot into the broken state, another one which in addition has the log messages for replugging the displayport cable to the other port. Please note that it does not matter whether the system boots with display connected DP-2 or DP-3. It shows the issue with both ports. But when I replug the cable from DP-2 to DP-3 or DP-3 to DP-2 depending on where it was connected during boot it always accepts the Full HD 60 Hz modes. And these work very stable. Also note: After a suspend to ram or a hibernation cycle the 60 Hz mode still works. It appears to me that the directly after boot mode detection is broken. Is there a way to override the maximum usable CLOCK as a work-around? I know it works. :) Created attachment 138674 [details]
kern.log with Intel driver not using fullhd 60hz mode on external display
Created attachment 138675 [details]
kern.log with Intel driver using fullhd 60hz mode after plugging dp cable to other port
The tests I did with drm debugging switch on have been with final 4.16 kernel as released by Linus. Ville, any advices from you? [ 6.553805] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:69:DP-2] Link Training failed at link rate = 162000, lane count = 4 [ 6.816030] [drm:intel_dp_start_link_train [i915]] [CONNECTOR:69:DP-2] Link Training failed at link rate = 270000, lane count = 2 etc. So the link appears to be somewhat marginal, sometimes it succeeds in training sometimes not. When it fails we drop it down to 2 x 1.62 Gbps, which means there isn't quite enough bandwidth for 1080p60. Unfortunately I don't have a good theory as to why it would be flaky after boot but then somehow keep working if the cable is swapped to the other port. (Removing NEEDINFO, as I think I provided the requested information.) As I described in my initial mail, on some, rare boot attempts sddm and then usually Plasma shows the non interlaced 1920 x 1080 mode. So sometimes it is not necessary to replug the display port cable to the other port. But so far in case it showed the interlaced mode replugging the display port cable to the other port worked in 100% of the cases (but means I had to duplicate some Plasma desktop configuration to work in either case). The issue still happens with 4.16.3. I did not see this with 4.17-rc4, so probably this issue has been fixed. I am setting as WORKSFORME, since I can not confirm that there has been a fix in the code. Good enough, thanks! Closing, please reopen if re-occurs. |
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.