Created attachment 128283 [details] dmesg Laptop : Inspiron 15 Gaming 7566 Distro : Xubuntu 16.04 CPU : Intel i7-6700HQ + HD 530 Additional GPU : Nvidia GeForce GTX 960M What happens : The only way to have an external monitor recognized via HDMI is to have it plugged at boot. Attempting to hotplug an HDMI monitor later on always fails. Reproduce rate : every time. Tested on kernels 4.4 and 4.9-rc6. dmesg note : Kernel 4.9-rc6, without nouveau. The PC boots with the HDMI monitor plugged in (working), and at ~70s I unplug/replug it (not working anymore). xrandr note : xrandr --verbose while the monitor was still plugged in and functional. Hotplugging results in only eDP1 being recognized. Additional notes : Tried with and without nouveau. Both result in the same behaviour.
Created attachment 128284 [details] xrandr xrandr --verbose
EDID read failed. Could you check if EDID is available via any other i2c gmbus: # modprobe i2c-dev # i2cdump -y <bus_num> 0x40 i You can get the available gmbus instances with: # i2cdetect -l
(In reply to Imre Deak from comment #2) > EDID read failed. Could you check if EDID is available via any other i2c > gmbus: > # modprobe i2c-dev > # i2cdump -y <bus_num> 0x40 i Sorry wong address, with the correct one: # i2cdump -y <bus_num> 0x50 i > > You can get the available gmbus instances with: > # i2cdetect -l
$ sudo i2cdetect -l i2c-3 i2c DPDDC-A I2C adapter i2c-1 i2c i915 gmbus dpb I2C adapter i2c-6 i2c Synopsys DesignWare I2C adapter I2C adapter i2c-4 i2c DPDDC-B I2C adapter i2c-2 i2c i915 gmbus dpd I2C adapter i2c-0 i2c i915 gmbus dpc I2C adapter i2c-5 i2c Synopsys DesignWare I2C adapter I2C adapter $ sudo i2cdump -y 0 0x50 i Error: Block read failed, return code -1 $ sudo i2cdump -y 1 0x50 i Error: Block read failed, return code -1 $ sudo i2cdump -y 2 0x50 i Error: Block read failed, return code -1 I ran these commands while the external monitor was plugged in and functional (from boot). Should I run them with the monitor hotplugged and not working ?
(In reply to raptorteak from comment #4) I'm guessing that you have an LSPCON DP->HDMI adaptor on the board and your kernel missing the support for it. You could check with: # i2cdump -y 4 0x40 i If that succeeds (should return the adaptor ID), could you try the drm-tip branch from: git://anongit.freedesktop.org/drm-tip That includes LSPCON support.
Created attachment 128290 [details] dmesg-drm-tip HDMI unplug at ~ 48s. HDMI replug at ~ 66s.
$ sudo i2cdump -y 4 0x40 i 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? 10: a8 00 1c f8 50 53 31 37 35 30 b0 00 00 78 0f 00 ?.??PS1750?..x?. 20: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ..?............. 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40: 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Looks like you are right about the adapter. However, drm-tip didn't do the trick :< . Unless there is a specific config to enable ? Above is a newer dmesg from the drm-tip run.
(In reply to raptorteak from comment #7) > $ sudo i2cdump -y 4 0x40 i > 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef > 00: 44 50 2d 48 44 4d 49 20 41 44 41 50 54 4f 52 04 DP-HDMI ADAPTOR? > 10: a8 00 1c f8 50 53 31 37 35 30 b0 00 00 78 0f 00 ?.??PS1750?..x?. > 20: 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 ..?............. > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 40: 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ??.............. > 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > Looks like you are right about the adapter. However, drm-tip didn't do the > trick :< . Unless there is a specific config to enable ? > > Above is a newer dmesg from the drm-tip run. Thanks, LSPCON is enabled now and the monitor is detected during bootup, but after replug the adaptor's AUX channel is down for some reason, so detection will fail. One possibility is that the adaptor switches to LS mode during unplug and we have to switch back to PCON mode. Could you get the same i2cdump as above after replugging and try the following patch: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 9dfbde4..96809cf 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4101,9 +4101,13 @@ intel_dp_short_pulse(struct intel_dp *intel_dp) static enum drm_connector_status intel_dp_detect_dpcd(struct intel_dp *intel_dp) { + struct intel_lspcon *lspcon = dp_to_lspcon(intel_dp); uint8_t *dpcd = intel_dp->dpcd; uint8_t type; + if (lspcon->active) + lspcon_resume(lspcon); + if (!intel_dp_get_dpcd(intel_dp)) return connector_status_disconnected;
Awesome, that did it. I can now unplug/replug and the new monitor is always detected (and usable). Works like a charm overall. The i2cdump remains exactly the same, although I'm not quite sure when you wanted me to do it (before/after patch?). Cheers!
(In reply to raptorteak from comment #9) > Awesome, that did it. I can now unplug/replug and the new monitor is always > detected (and usable). Works like a charm overall. > > The i2cdump remains exactly the same, although I'm not quite sure when you > wanted me to do it (before/after patch?). Great, thanks for trying it! Sorry, I meant with drm-tip, before the patch and after unplug/replug, to see if the adaptor really did switch to LS mode on its own as we suspected (offset 0x40 tells that). But it'd would be enough if you could still provide a dmesg with the patch including the unplug/replug event, that would also show what's going on. Thanks! > > Cheers!
Created attachment 128296 [details] dmesg-drm-tip-patched Unplug ~106s Replug ~119s
(In reply to raptorteak from comment #11) > Created attachment 128296 [details] > dmesg-drm-tip-patched > > Unplug ~106s > Replug ~119s Ok, looks like it's changing to LS mode on its own. It's somewhat surprising, perhaps done for power saving. I'll follow up with a patch with a fix, we can close the bug once that gets merged. Thanks for your help!
Created attachment 129802 [details] [review] Set short HPD signaling Could you give a try if the attached patch on top of drm-tip also fixes the problem? That is without the change in comment 8.
Created attachment 129827 [details] dmesg_2017_02_22
Hey Imre, I'm afraid this doesn't work. Here's the dmesg with drm.debug=0xe. As usual, computer booted with HDMI plugged in, unplug at ~26s, replug at ~36s.
(In reply to raptorteak from comment #15) > Hey Imre, > > I'm afraid this doesn't work. Here's the dmesg with drm.debug=0xe. > As usual, computer booted with HDMI plugged in, unplug at ~26s, replug at > ~36s. Thanks. Ok, I tried this based on Ville's earlier idea to switch from long to short HPD pulses. That is how normally branch devices work and that is how the MegaChips LSPCON adaptor works too (although that one uses short pulses regardless of the branch control HPD flag value). In any case your LSPCON adaptor rejects the setting of this flag with an AUX NAK, so my bet is that it doesn't support this. Based on the above my solution would be still the change in comment 8, I'll send a patch with that.
Created attachment 129873 [details] dmesg_patch_no_longer_working Just wanted to say that your current patch (V2) does no longer work with current drm-tip. The process goes further than unpatched since I can see EDID negotiation in dmesg but sadly the power seems to be turned off anyway, and the screen stays in "no signal" mode.
Wooops, nevermind, It does work perfectly. I was just surprised that xfce didn't show a popup that something was hotplugged, but going into the display settings I can enable the monitor and it works as expected. Sorry, false alert.
(In reply to raptorteak from comment #18) > Wooops, nevermind, It does work perfectly. I was just surprised that xfce > didn't show a popup that something was hotplugged, but going into the > display settings I can enable the monitor and it works as expected. Sorry, > false alert. Right. I did see in your log the change from LS to PCON mode after replug as expected and then detection succeeding and setting the connector state to connected. After that there was just no modeset from userspace, as you would expect after a disconnected->connected uevent. But it looks like you figured the reason for that.
Imre what is the next step look like the patch works, should I place this bug as resolved? And once integrated and verified we can close it?
(In reply to Ricardo from comment #20) > Imre what is the next step look like the patch works, should I place this > bug as resolved? Yes, the patch is merged now. I set this now to resolved. > > And once integrated and verified we can close it? Yes, can be closed once the reporter has verified it.
Can confirm the bug is fixed using drm-tip from 2017/03/04
(In reply to raptorteak from comment #22) > Can confirm the bug is fixed using drm-tip from 2017/03/04 Thanks for the follow-up!
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.