Bug 1126287

Something for Oli, as it seems.

Please attach /var/log/Xorg.0.log and the output of

  xrandr

Thanks!

Created attachment 797587 [details]
xorg log + xrandr output

I forgot to mention, it works when booting  with 15.0's kernel 4.12.14-lp150.12.48-default

Intel Skylake

Ok. Seems with 15.1 one of the monitor is only detected with a native resolution of 1024x768 (DP-1-1-1) and

--- Xorg.0-15.0.log.formatted 
+++ Xorg.0-15.1.log.formatted

- (II) modeset(0): Using spanning desktop for initial modes
- (II) modeset(0): Output eDP-1 using initial mode 1920x1080 +0+0
- (II) modeset(0): Output DP-1-1 using initial mode 1920x1080 +1920+0
- (II) modeset(0): Output DP-1-2-8 using initial mode 1920x1080 +3840+0
+ (II) modeset(0): Using fuzzy aspect match for initial modes
+ (II) modeset(0): Output eDP-1 using initial mode 1024x768 +0+0
+ (II) modeset(0): Output DP-1-1 using initial mode 1024x768 +0+0
+ (II) modeset(0): Output DP-1-2-8 using initial mode 1024x768 +0+0

On 15.1 you're using an interesting monitor layout with at least one monitor rotated. On 15.1 it's just three monitors side-by-side with the smallest one detected (1024x768) on the right side.

Looks like a kernel/DRM/KMS problem to me.

I could reproduce a similar problem with Dell WD15 dock, too.  Only one monitor on the dock was detected and only with 1024x768.  Meanwhile, connecting on the laptop's built-in HDMI works.

FWIW, the upstream 4.19.y and 4.20.y kernels work fine, it could detect the dock video outputs properly.  That indicates that the problem isn't in DRM but rather in the PCI core side.

I compiled kernel 4.14.102 from kernel.org with CONFIG_HOTPLUG_PCI_SHPC=m,
and it works.
I had tried to do the same with kernel-source-4.12.14-lp151.21.7.noarch , I cannot have CONFIG_HOTPLUG_PCI_SHPC=m : only N or y are available. So I cannot build the shpchp module.
The issue happens when CONFIG_HOTPLUG_PCI_SHPC is set to "y" or not set.

We have backports in our 4.12.14-lp151.21 from Kernel 4.19. So this is newer than what you've tested with 4.14.102. Anyway, kernel 4.19/4.20 with CONFIG_HOTPLUG_PCI_SHPC=y work fine. Takashi just gave it a try. 

So the issue is in our backports. :-(

Sorry, my last message was very badly phrased. I have not tried to compile 4.14 with "y", only with "m". What I tried is to compile the module on 4.12.14-lp151.21, which was not possible, then either "y" or unset give exactly the same result.

I tried bisection, and this lead to the i915 commit:
bfb4810c4c5a30363c4517c5501cab6c9eff51e7
    drm/i915: Fix hpd handling for pins with two encoders (bsc#1113956)

The upstream commit is 5a3aeca97af1b6b3498d59a7fd4e8bb95814c108.

I'm building a test kernel with the revert of this patch.  It's being built in OBS home:tiwai:bsc1126287 repo.  Could you try it later once after the build finishes?

But, even if the revert helps, it's still puzzling why 4.19.y and 4.20.y kernels worked; they contain the commit above (although it's in 5.0-rc1) though stable updates.

Hi, everything works as expected with 4.12.14-1.gf4b453d-default.

OK, I pushed the revert now to SLE15-SP1 branch.

Will keep investigating further why it triggers a problem.

After further investigation, I found the reason why 4.19.y and 4.20.y work.

Actually they have a slightly different backport from 5.0-rc.  It has the additional check the Linus tree doesn't contain.  The chunk looks like:

-               if (!has_hpd_pulse) {
+               /*
+                * Delegate to ->hpd_pulse() if one of the encoders for this
+                * pin has it, otherwise let the hotplug_work deal with this
+                * pin directly.
+                */
+               if (((short_hpd_pulse_mask | long_hpd_pulse_mask) & BIT(pin))) {
+                       long_hpd = long_hpd_pulse_mask & BIT(pin);
+               } else {
                        dev_priv->hotplug.event_bits |= BIT(pin);
+                       long_hpd = true;
                        queue_hp = true;
                }
 
+               if (!long_hpd)
+                       continue;

... and the last one "if (!long_hpd) continue" doesn't exist in 5.0-rc code.
Adding this makes thing working again.

Interestingly, 5.0-rc works without that, and it's likely because of the rework of HPD handling itself.

The corrected patch is revived and pushed again to my SLE15-SP1 branch now.

*** Bug 1126840 has been marked as a duplicate of this bug. ***

FYI, the latest fixed kernel is found in OBS home:tiwai:bsc1126287-2 repo:
  https://download.opensuse.org/repositories/home:/tiwai:/bsc1126287-2/standard/

(In reply to Takashi Iwai from comment #15)
> FYI, the latest fixed kernel is found in OBS home:tiwai:bsc1126287-2 repo:
>  
> https://download.opensuse.org/repositories/home:/tiwai:/bsc1126287-2/
> standard/

This kernel addresses my issue with Dell WD15 docking station and Lattitude 7480.
I am using Wayland not X11.

You have to disable Secure Boot using such test kernels - can be switched on again as soon as we have the fix in a regular openSUSE build. Only official builds will provide correctly signed kernel.

(In reply to Takashi Iwai from comment #13)
> The corrected patch is revived and pushed again to my SLE15-SP1 branch now.

Closing as fixed.

Fix verified