I refer to bug 1816860 on Ubuntu Launchpad My dual-boot recognizes and switches to the second monitor under W10, it seems that kubuntu 18.04 does not recognize that monitor, and does not offer to use it. The results of xrandr and some in /sys/class/drm can be found in that report, where it was suggested to file a bug here for the part of it that it doesn't see any second monitor. I'll be happy to help as far as I can to get my setup running.
*** Bug 109751 has been marked as a duplicate of this bug. ***
Created attachment 143442 [details] EDID communication from W10 is possible
I tried another cable, even a proper Samsung monitor (contrary to the digital TV as before). Nothing at all. In W10 the lenovo diagnostics does correctly receive and handle the EDID-data. I tried all other dock functionalities, like Ethernet, headphone. All work properly under *nix out of the box. (Actually I had bought that dock because it doesn't need drivers, lenovo doesn't offer any. It connects to the dock connector on the tablet instead of through USB 3.0 like all other docks).
Okay, one small step further: I checked in the BIOS, and it offers the following three as primary displays: ThinkPad LCD Digital on ThinkPad Display on Dock Previously I used to see udippel@Uwe-ThinkPad-Helix-2nd:~$ grep . /sys/class/drm/*/enabled /sys/class/drm/card0-eDP-1/enabled:enabled /sys/class/drm/card0-HDMI-A-1/enabled:disabled /sys/class/drm/card0-HDMI-A-2/enabled:disabled udippel@Uwe-ThinkPad-Helix-2nd:~$ grep . /sys/class/drm/*/status /sys/class/drm/card0-eDP-1/status:connected /sys/class/drm/card0-HDMI-A-1/status:disconnected /sys/class/drm/card0-HDMI-A-2/status:disconnected udippel@Uwe-ThinkPad-Helix-2nd:~$ grep . /sys/class/drm/*/dpms /sys/class/drm/card0-eDP-1/dpms:On /sys/class/drm/card0-HDMI-A-1/dpms:Off /sys/class/drm/card0-HDMI-A-2/dpms:Off Then I attached a cable from the micro-HDMI-port on the side of the ThinkPad to the monitor. Quite following the obvious logic, what I get is udippel@Uwe-ThinkPad-Helix-2nd:~$ grep . /sys/class/drm/*/enabled /sys/class/drm/card0-eDP-1/enabled:enabled /sys/class/drm/card0-HDMI-A-1/enabled:enabled /sys/class/drm/card0-HDMI-A-2/enabled:disabled udippel@Uwe-ThinkPad-Helix-2nd:~$ grep . /sys/class/drm/*/status /sys/class/drm/card0-eDP-1/status:connected /sys/class/drm/card0-HDMI-A-1/status:connected /sys/class/drm/card0-HDMI-A-2/status:disconnected udippel@Uwe-ThinkPad-Helix-2nd:~$ grep . /sys/class/drm/*/dpms /sys/class/drm/card0-eDP-1/dpms:On /sys/class/drm/card0-HDMI-A-1/dpms:On /sys/class/drm/card0-HDMI-A-2/dpms:Off So the 'Digital on ThinkPad' seems to be the connector on the side of the tablet. It checks. Logically the third entry, HDMI-A-2 will be the Display on Dock. And there it looks like whatever display, it cannot be detected as 'connected'. xrandr follows the same logic: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 eDP-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 256mm x 144mm 1920x1080 59.99 + 59.97* 59.96 59.93 1680x1050 59.95 59.88 1600x1024 60.17 1400x1050 59.98 1600x900 59.99 59.94 59.95 59.82 1280x1024 60.02 1440x900 59.89 1400x900 59.96 59.88 1280x960 60.00 1440x810 60.00 59.97 1368x768 59.88 59.85 1360x768 59.80 59.96 1280x800 59.99 59.97 59.81 59.91 1152x864 60.00 1280x720 60.00 59.99 59.86 59.74 1024x768 60.04 60.00 960x720 60.00 928x696 60.05 896x672 60.01 1024x576 59.95 59.96 59.90 59.82 960x600 59.93 60.00 960x540 59.96 59.99 59.63 59.82 800x600 60.00 60.32 56.25 840x525 60.01 59.88 864x486 59.92 59.57 800x512 60.17 700x525 59.98 800x450 59.95 59.82 640x512 60.02 720x450 59.89 700x450 59.96 59.88 640x480 60.00 59.94 720x405 59.51 58.99 684x384 59.88 59.85 680x384 59.80 59.96 640x400 59.88 59.98 576x432 60.06 640x360 59.86 59.83 59.84 59.32 512x384 60.00 512x288 60.00 59.92 480x270 59.63 59.82 400x300 60.32 56.34 432x243 59.92 59.57 320x240 60.05 360x202 59.51 59.13 320x180 59.84 59.32 HDMI-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 708mm x 398mm 1920x1080 60.00*+ 50.00 59.94 30.00 24.00 29.97 23.98 1920x1080i 60.00 50.00 59.94 1280x1024 60.02 1280x720 60.00 50.00 30.00 59.94 29.97 24.00 23.98 1024x768 60.00 800x600 60.32 720x576 50.00 720x576i 50.00 720x480 60.00 59.94 720x480i 60.00 59.94 640x480 60.00 59.94 HDMI-2 disconnected (normal left inverted right x axis y axis) A hardware error is not to be expected: The dock is new, and moreover W10 communicates with it (using the W10-based graphics utility for the HD5300).
Created attachment 143454 [details] dmesg log
(In reply to Lakshmi from comment #5) > Created attachment 143454 [details] > dmesg log Atached dmesg from ubuntu launchpad bug 1816860.
Attached dmesg log is from kernel 4.15. Can you verify the issue with latest kernel/drmtip? (https://cgit.freedesktop.org/drm-tip)
(In reply to Lakshmi from comment #7) > Attached dmesg log is from kernel 4.15. Can you verify the issue with > latest kernel/drmtip? > (https://cgit.freedesktop.org/drm-tip) Reporter, have you verified the issue with latest drmtip?
Yes, I have verified that 5.0.0-050000 behaves likewise. I have left everything in place, just booting to W10 (works), reboot the dual-boot to 5.0.0-0500000 (March 7th), and no display, and no output of xrandr for any display except of the built-in one.
(In reply to Uwe Dippel from comment #9) > Yes, I have verified that 5.0.0-050000 behaves likewise. > I have left everything in place, just booting to W10 (works), reboot the > dual-boot to 5.0.0-0500000 (March 7th), and no display, and no output of > xrandr for any display except of the built-in one. Since you have verified the issue with drmtip, Can you please attach the dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M? Logs from drmtip testing would be helpful during investigation.
(In reply to Uwe Dippel from comment #9) > Yes, I have verified that 5.0.0-050000 behaves likewise. > I have left everything in place, just booting to W10 (works), reboot the > dual-boot to 5.0.0-0500000 (March 7th), and no display, and no output of > xrandr for any display except of the built-in one. Can you please attach this log?
Created attachment 143837 [details] kernel log while trying to connect
Ville, any help here?
Hmm. Could be the BIOS has a borked VBT. Looks like you're booting in EFI mode so it shouldn't be due to busted legacy mode support in the BIOS (which is somewhat common). Please attach a copy of /sys/kernel/debug/dri/0/i915_vbt Also when you have the external display connected to the dock please do this as root: "modprobe i2c-dev ; for i in `seq 0 9` ; do i2cdetect -y $i 0x50 0x50 ; done" and attach the result here. That should tell is if an EDID can be detected on any i2c bus. Is the BIOS capable of lighting up the external display on the dock? If yes, it would be helpful if you can boot without loading i915 (eg. pass modprobe.blacklist=i915,snd_hda_intel to the kernel cmdline and prevent all gui stuff from starting up). Once up and running w/o i915 loaded you should grab a register dump with "intel_reg dump" and attach here. intel_reg is part of igt: git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Uwe, any updates here? Can you please follow the instructions given in Comment 14 and attach all required information. This is needed to proceed further with the investigation.
(In reply to Ville Syrjala from comment #14) > Hmm. Could be the BIOS has a borked VBT. Looks like you're booting in EFI > mode so it shouldn't be due to busted legacy mode support in the BIOS (which > is somewhat common). > > Please attach a copy of /sys/kernel/debug/dri/0/i915_vbt > > Also when you have the external display connected to the dock please do this > as root: > "modprobe i2c-dev ; for i in `seq 0 9` ; do i2cdetect -y $i 0x50 0x50 ; done" > and attach the result here. That should tell is if an EDID can be detected > on any i2c bus. > > Is the BIOS capable of lighting up the external display on the dock? If yes, > it would be helpful if you can boot without loading i915 (eg. pass > modprobe.blacklist=i915,snd_hda_intel to the kernel cmdline and prevent all > gui stuff from starting up). Once up and running w/o i915 loaded you should > grab a register dump with "intel_reg dump" and attach here. intel_reg is > part of igt: git://anongit.freedesktop.org/xorg/app/intel-gpu-tools (In reply to Lakshmi from comment #15) > Uwe, any updates here? Can you please follow the instructions given in > Comment 14 and attach all required information. This is needed to proceed > further with the investigation. No feedback from more than a month. Dropping the Priority to Medium.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/701.
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.