Kernel vision: drm-intel-nightly, cod/tip/drm-tip/2018-12-19. When booting the system without HDMI cable plugged, the system can never detect HDMI cable afterward. This issue is not observed when HDMI cable is plugged before boot, LSPCON gets probed successfully in this case. HDMI hotplug also works in this case. I tried to increase both retry count and sleep time in lspcon_probe(), but it doesn't make any difference.
Created attachment 142857 [details] HDMI cable plugged before boot, LSPCON works
Created attachment 142858 [details] HDMI cable _not_ plugged before boot, LSPCON doesn't work
I also tested Windows 10. HDMI still works when the cable wasn't plugged before boot.
Swati, any comments here?
Hi Kai-Heng-Feng, To re-create same test scenario can be please elaborate how you are testing? 1. Booting with which connector attached (if not HDMI)? 2. After booting, are you doing hot-unplug of previous connector attached and hot-plug of HDMI connector? 3. After hot-plug of HDMI cable, are you seeing any blank screen/no signal? 4. Are you executing any test?
Hi, Swati, 1. No any connector attached. 2. If HDMI cable is plugged before boot, it will always have signal no matter how you hot-unplug and hot-plug HDMI. 3. If HDMI cable isn't connected before boot, It's always blank screen when we hot-plug the cable. 4. No, just normal boot up.
Thanks Hugh Chao for the info. Seeing the logs where the LSP-Con works, LSP-Con chip being used is from Parade Tech. Can you please confirm whether you are seeing this issue in MCA LSP-Con chips as-well?
(In reply to Swati Sharma from comment #7) > Thanks Hugh Chao for the info. Seeing the logs where the LSP-Con works, > LSP-Con chip being used is from Parade Tech. Can you please confirm whether > you are seeing this issue in MCA LSP-Con chips as-well? Is LSPCON chip swappable? The platform in question is already on the market so I am not sure it's feasible to test different LSPCON chips.
It's ok. There are 2 vendors of lspcon chip-Parade and MCA. Can you please provide following info: 1. cat /sys/kernel/debug/dri/0/i915_display_info 2. attach /sys/kernel/debug/dri/0/i915_vbt 3. are you using any external dongle/cable?
Created attachment 142971 [details] i915_display_info, HDMI cable plugged before boot
Created attachment 142972 [details] i915_display_info, HDMI cable plugged after boot
Created attachment 142973 [details] VBT info
(In reply to Swati Sharma from comment #9) > 3. are you using any external dongle/cable? Yes, it's a mini desktop so HDMI cable is required for this setup.
Any update?
Hi Wong, I tried replicating issue locally on kabylake gen9 platform, however couldn't succeed. No lspcon probe issue is observed. Configuration provided by you and mine is: <Swati> connector 83: type DP-1, status: connected DP branch device present: yes Type: HDMI ID: 175IB0 HW: 1.2 SW: 8.41 Max TMDS clock: 600000 kHz Max bpc: 12 <Kai-Heng Feng> connector 109: type DP-3, status: connected DP branch device present: yes Type: HDMI ID: 175IB0 HW: 1.0 SW: 7.35 Max TMDS clock: 600000 kHz Max bpc: 12 Here the difference is in HW and SW f/w. I will recommend you to please update to the latest sw f/w and test again. Since Linux F/W Flash Tool is not ready yet to update the f/w, you can update f/w by booting with windows first and using their AuxUpdate tool. In the logs of the failed case we can see "Native AUX CH down" and after that probe issue comes. May be in the latest s/w f/w issue would have been resolved from the parade, if this needs a h/w update (which hopefully shouldn't be the case) then nothing can be done. So, first update the s/w f/w, test and share your observation; only then we can take further steps.
Kai, have you verified the issue by updating fw? Any updates here?
(In reply to Lakshmi from comment #16) > Kai, have you verified the issue by updating fw? Any updates here? The system was sent to HP and I don't know the follow-up. Maybe Hugh can answer your question...
HP is still working on it, I'll feedback if I got any news
Same issue happens after the LSPCON FW update. Seems like the HW and SW info also get cleared out: connector 111: type DP-3, status: connected name: physical dimensions: 510x290mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ID: HW: 0.0 SW: 0.0 Max TMDS clock: 600000 kHz Max bpc: 12
Created attachment 143785 [details] Dmesg from drm-tip 2019-03-26 Same message: [ 2.267472] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon [ 2.267499] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
(In reply to Kai-Heng Feng from comment #20) > Created attachment 143785 [details] > Dmesg from drm-tip 2019-03-26 > > Same message: > [ 2.267472] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon > [ 2.267499] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on > port D What is the FW version here?
(In reply to Lakshmi from comment #22) > (In reply to Kai-Heng Feng from comment #20) > > Created attachment 143785 [details] > > Dmesg from drm-tip 2019-03-26 > > > > Same message: > > [ 2.267472] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon > > [ 2.267499] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on > > port D > > What is the FW version here? Please refer to comment #19.
FWIW I don't think the lspcon firmware matters here - as Windows doesn't have this issue on the old firmware.
(In reply to Hugh Chao from comment #18) > HP is still working on it, I'll feedback if I got any news Hi Hugh, Can you please elaborate what HP guys did to the system? What kind of changes they made?
(In reply to Kai-Heng Feng from comment #24) > FWIW I don't think the lspcon firmware matters here - as Windows doesn't > have this issue on the old firmware. Correct. Give me some time to debug. Will update.
(In reply to Swati Sharma from comment #25) > (In reply to Hugh Chao from comment #18) > > HP is still working on it, I'll feedback if I got any news > > Hi Hugh, > Can you please elaborate what HP guys did to the system? What kind of > changes they made? Hi Swati, The new FW which provided by HP is not working either. But our QA leader judged that video failed after booting by hot-plug is not a blocking issue, so we lower the priority of this issue. Thanks.
(In reply to Kai-Heng Feng from comment #3) > I also tested Windows 10. HDMI still works when the cable wasn't plugged > before boot. Hi Kai-Heng Feng, If we go by theory, there is no 1:1 mapping of Windows and Linux driver architecture. Design for lsp-con is different in both. In Windows, you are able to probe lsp-con because during hotplug windows drivers reinitialize all the connectors whereas in linux, connectors are initialized only once. It means during boot time, if lspcon is not probbed..we won't be able to probe it during hotplug. Since I am not having the same setup, I can't reproduce the issue. Give me some time so that I can arrange for the setup and get back to you.
(In reply to Hugh Chao from comment #27) > (In reply to Swati Sharma from comment #25) > > (In reply to Hugh Chao from comment #18) > > > HP is still working on it, I'll feedback if I got any news > > > > Hi Hugh, > > Can you please elaborate what HP guys did to the system? What kind of > > changes they made? > > Hi Swati, > > The new FW which provided by HP is not working either. But our QA leader > judged that video failed after booting by hot-plug is not a blocking issue, > so we lower the priority of this issue. Thanks. Sure.
(In reply to Swati Sharma from comment #28) > (In reply to Kai-Heng Feng from comment #3) > > I also tested Windows 10. HDMI still works when the cable wasn't plugged > > before boot. > > Hi Kai-Heng Feng, > > If we go by theory, there is no 1:1 mapping of Windows and Linux driver > architecture. Design for lsp-con is different in both. In Windows, you are > able to probe lsp-con because during hotplug windows drivers reinitialize > all the connectors whereas in linux, connectors are initialized only once. > It means during boot time, if lspcon is not probbed..we won't be able to > probe it during hotplug. I understand Linux and Windows driver are quite different. My point was, whether lspcon firmware has a bug or not is moot - software alone can make it work, or at least workaround it. > > Since I am not having the same setup, I can't reproduce the issue. Give me > some time so that I can arrange for the setup and get back to you. Sure, thanks for your effort.
I can't reproduce on a Gigabyte nuc like machine with Parade LSPCON. OUI 00-1c-f8 dev-ID 175IB0 HW-rev 1.0 SW-rev 7.32 So probably either a firmware difference or the chip is wired up differently on the boards causing it to not respond for you until HPD gets asserted. We should probably change the lspcon code to behave more dynamically and not insist on being able to probe the chip at driver load time.
(In reply to Ville Syrjala from comment #31) > I can't reproduce on a Gigabyte nuc like machine with Parade LSPCON. > OUI 00-1c-f8 dev-ID 175IB0 HW-rev 1.0 SW-rev 7.32 AFAIK this bug doesn't happen on other desktop systems. > > So probably either a firmware difference or the chip is wired up differently > on the boards causing it to not respond for you until HPD gets asserted. We > should probably change the lspcon code to behave more dynamically and not > insist on being able to probe the chip at driver load time. Ok, please just let me know when there's a patch to test.
@Swati, any updates here? What are the next steps?
In the motherboard down mode, LSPCON is supposed to be powered on with the power supply from the board, and hence, it was supposed to be powered-on during the driver probe time. So if it's not getting powered on during probe, this seems like a board design error, and not a SW issue. (This is probably expecting LSPCON to work in dongle mode, which we do not support in driver). That also explains why we are not able to reproduce this issue with other parade based devices. In order to work around this issue, we can add LSPCON probing in the hot-plug sequence, but that might come up with its own hotplug stability issues, like if the I2C over Aux bus is not stable yet, that might delay the hotplug handling path by adding some retries. Also, this is only possible when the display master IRQ is getting the HPD interrupt, but it's getting missed due to unavailability on the connector on port. But as the IRQ signal is also coming via LSPCON, which is not powered-on until hotplug, there is also a possibility of missing the hotplug all-together, in which case, moving the probe is not going to help at all. - Shashank
(In reply to shashank.sharma@intel.com from comment #34) > In the motherboard down mode, LSPCON is supposed to be powered on with the > power supply from the board, and hence, it was supposed to be powered-on > during the driver probe time. So if it's not getting powered on during > probe, this seems like a board design error, and not a SW issue. (This is > probably expecting LSPCON to work in dongle mode, which we do not support in > driver). That also explains why we are not able to reproduce this issue with > other parade based devices. Ok we'll let vendor know about this. > > In order to work around this issue, we can add LSPCON probing in the > hot-plug sequence, but that might come up with its own hotplug stability > issues, like if the I2C over Aux bus is not stable yet, that might delay the > hotplug handling path by adding some retries. We can use a DMI based quirk so other platforms won't be penalized. > > Also, this is only possible when the display master IRQ is getting the HPD > interrupt, but it's getting missed due to unavailability on the connector on > port. But as the IRQ signal is also coming via LSPCON, which is not > powered-on until hotplug, there is also a possibility of missing the hotplug > all-together, in which case, moving the probe is not going to help at all. This doesn't explain why Windows doesn't have this issue, it can reliably detect hot plugging event everytime. > > - Shashank
I have a new Dell Precision 7540 that came with OEM Ubuntu LTS and I have the same errors in Ubuntu LTS and Arch stable and I also tried Kubuntu 19.10. So on all kernels and all Distro's I guess. I have both Intel and AMD Graphics and I am using the modesetting i915 driver as default. I also have the mesa hardware acceleration driver installed and xf86-video-amdgpu installed. Operating System: Arch Linux KDE Plasma Version: 5.17.1 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 Kernel Version: 5.3.7-arch1-1-ARCH OS Type: 64-bit Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 15.4 GiB of RAM [josh@archkde ~]$ dmesg --level=err,warn [ 0.462839] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. [ 0.501892] #7 #8 #9 #10 #11 [ 0.669275] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 2.043797] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon [ 2.043822] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D
(In reply to Josh from comment #36) > I have a new Dell Precision 7540 that came with OEM Ubuntu LTS and I have > the same errors in Ubuntu LTS and Arch stable and I also tried Kubuntu > 19.10. So on all kernels and all Distro's I guess. I have both Intel and AMD > Graphics and I am using the modesetting i915 driver as default. I also have > the mesa hardware acceleration driver installed and xf86-video-amdgpu > installed. > > Operating System: Arch Linux > KDE Plasma Version: 5.17.1 > KDE Frameworks Version: 5.63.0 > Qt Version: 5.13.1 > Kernel Version: 5.3.7-arch1-1-ARCH > OS Type: 64-bit > Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz > Memory: 15.4 GiB of RAM > > > [josh@archkde ~]$ dmesg --level=err,warn > [ 0.462839] MDS CPU bug present and SMT on, data leak possible. See > https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more > details. > [ 0.501892] #7 #8 #9 #10 #11 > [ 0.669275] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' > [ 2.043797] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon > [ 2.043822] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on > port D Hi Josh, Can you confirm whether its MCA or Parade LSPCON? If its MCA, please update your FW. Intel download center for NUC devices has FW V 1.77 available, along with the flashing utility. -FW for Coffee Lake based NUC: https://downloadcenter.intel.com/download/29092/HDMI-Firmware-Update-Tool-for-NUC8i3BE-NUC8i5BE-NUC8i7BE -FW for our Kaby Lake NUC: https://downloadcenter.intel.com/download/29162/HDMI-Firmware-Update-Tool-for-NUC7i3BN-NUC7i5BN-NUC7i7BN?product=95067
@Swati Sharma in comment #37 I have now the latest firmware installed today as a matter of fact and all latest stable Arch Linux packages on KDE Plasma. I still have the same errors.I have linux-firmware 20191022.2b016af-3 Operating System: Arch Linux KDE Plasma Version: 5.17.3 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.2 Kernel Version: 5.3.11-arch1-1 OS Type: 64-bit Processors: 12 × Intel® Core™ i7-9750H CPU @ 2.60GHz Memory: 15.4 GiB of RAM [josh@archkde ~]$ dmesg --level=err,warn [ 0.468600] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details. [ 0.508039] #7 #8 #9 #10 #11 [ 0.675435] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 1.409892] nvme nvme0: missing or invalid SUBNQN field. [ 2.059893] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon [ 2.059922] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port D [ 2.093580] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [ 2.480212] i8042: PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp [ 2.482907] i8042: Warning: Keylock active [ 2.495290] usb: port power management may be unreliable [ 2.719009] acpi_call: loading out-of-tree module taints kernel. [ 3.071411] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [ 3.071468] wmi_bus wmi_bus-PNP0C14:03: WQBC data block query control method not found [ 3.071470] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [ 3.096930] acpi PNP0C14:04: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [ 3.151066] acpi PNP0C14:05: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [ 3.338228] ATPX version 1, functions 0x00000033 [ 3.350774] CRAT table not found [ 3.597350] i801_smbus 0000:00:1f.4: Accelerometer lis3lv02d is present on SMBus but its address is unknown, skipping registration [ 3.702897] kvm: disabled by bios [ 3.837421] sd 2:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) [ 3.847658] kvm: disabled by bios [ 3.967573] kvm: disabled by bios [ 4.064601] kvm: disabled by bios [ 4.096816] i2c_hid i2c-DELL0926:00: i2c-DELL0926:00 supply vdd not found, using dummy regulator [ 4.096824] i2c_hid i2c-DELL0926:00: i2c-DELL0926:00 supply vddl not found, using dummy regulator [ 4.179187] kvm: disabled by bios [ 4.286115] kvm: disabled by bios [ 4.311021] thermal thermal_zone10: failed to read out thermal zone (-61) [ 4.420065] kvm: disabled by bios [ 4.521085] iwlwifi 0000:6e:00.0: FW already configured (0) - re-configuring [ 4.538087] iwlwifi 0000:6e:00.0: BIOS contains WGDS but no WRDS [ 4.553037] kvm: disabled by bios [ 4.671331] kvm: disabled by bios [ 4.747121] iwlwifi 0000:6e:00.0: FW already configured (0) - re-configuring [ 4.761995] iwlwifi 0000:6e:00.0: BIOS contains WGDS but no WRDS [ 4.832256] kvm: disabled by bios [ 4.939154] kvm: disabled by bios [ 4.948168] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out! [ 5.057694] kvm: disabled by bios [ 5.461537] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out! [ 7.347171] kauditd_printk_skb: 13 callbacks suppressed [ 12.792640] iwlwifi 0000:6e:00.0: FW already configured (0) - re-configuring [ 12.801911] iwlwifi 0000:6e:00.0: BIOS contains WGDS but no WRDS [ 15.715340] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out! [ 16.215345] [drm:hwss_edp_wait_for_hpd_ready [amdgpu]] *ERROR* hwss_edp_wait_for_hpd_ready: wait timed out! [ 17.862666] kauditd_printk_skb: 5 callbacks suppressed
Swati comment #37 if I could ask a question here please. So you your telling me that I should try and update the HDMI firmware on a laptop. I mean I thought this would be part of the BIOS updates would it not??? My Bios just got updated on Oct 16th so I should have the newest firmware Dell has to offer for my HDMI port. My laptop does have a full size HDMI but as far as if it is a being a MCA or Parade LSPCON I have no clue. I get this error every single boot though I do know that for a fact and have gotten it since I bought the laptop new 1 1/2 months ago. The laptop came with Ubuntu and like I have said I have updated the Bios twice since I have had it. I am on Arch Linux with all the latest stable Kernel packages Arch has to offer so it is a problem. Oh I don't and have never had anything HDMI. I know us the people of the Linux world have to deal with errors so I have just been using the PC but I really hate to see them so I wish we could get a fix.Thanks .
If you have something like: Connector info -------------- connector 71: type DP-1, status: connected name: physical dimensions: 640x400mm subpixel order: Unknown CEA rev: 3 DPCD rev: 12 audio support: yes DP branch device present: yes Type: HDMI ======> ID: 175IB0 HW: 1.0 SW: 7.32 Max TMDS clock: 600000 kHz Max bpc: 12 This is Parade Chip. If you have like... connector 95: type DP-1, status: connected physical dimensions: 540x350mm subpixel order: Unknown CEA rev: 0 DPCD rev: 12 audio support: no DP branch device present: yes Type: HDMI =====> ID: MC2800 HW: 2.2 SW: 1.77 Max TMDS clock: 600000 kHz Max bpc: 16 HDCP version: HDCP1.4 modes: This is MCA
(In reply to Jani Saarinen from comment #40) > If you have something like: > > Connector info > -------------- > connector 71: type DP-1, status: connected > name: > physical dimensions: 640x400mm > subpixel order: Unknown > CEA rev: 3 > DPCD rev: 12 > audio support: yes > DP branch device present: yes > Type: HDMI > ======> ID: 175IB0 > HW: 1.0 > SW: 7.32 > Max TMDS clock: 600000 kHz > Max bpc: 12 > > This is Parade Chip. > > > If you have like... > connector 95: type DP-1, status: connected > physical dimensions: 540x350mm > subpixel order: Unknown > CEA rev: 0 > DPCD rev: 12 > audio support: no > DP branch device present: yes > Type: HDMI > =====> ID: MC2800 > HW: 2.2 > SW: 1.77 > Max TMDS clock: 600000 kHz > Max bpc: 16 > HDCP version: HDCP1.4 > modes: > > This is MCA What command are you using to see this info??? I am on Arch but if you can just give me whatever command you are using then maybe I can figure it out.
(In reply to Jani Saarinen from comment #40) > If you have something like: > > Connector info > -------------- > connector 71: type DP-1, status: connected > name: > physical dimensions: 640x400mm > subpixel order: Unknown > CEA rev: 3 > DPCD rev: 12 > audio support: yes > DP branch device present: yes > Type: HDMI > ======> ID: 175IB0 > HW: 1.0 > SW: 7.32 > Max TMDS clock: 600000 kHz > Max bpc: 12 > > This is Parade Chip. > > > If you have like... > connector 95: type DP-1, status: connected > physical dimensions: 540x350mm > subpixel order: Unknown > CEA rev: 0 > DPCD rev: 12 > audio support: no > DP branch device present: yes > Type: HDMI > =====> ID: MC2800 > HW: 2.2 > SW: 1.77 > Max TMDS clock: 600000 kHz > Max bpc: 16 > HDCP version: HDCP1.4 > modes: > > This is MCA I think it is MCA then maybe. Connector info -------------- connector 86: type eDP-1, status: connected physical dimensions: 340x190mm subpixel order: Unknown CEA rev: 0 DPCD rev: 12 audio support: no fixed mode: "1920x1080": 60 152840 1920 1968 2000 2250 1080 1086 1094 1132 0x48 0x9 DP branch device present: no modes: "1920x1080": 60 152840 1920 1968 2000 2250 1080 1086 1094 1132 0x48 0x9 "1920x1080": 48 152840 1920 1968 2000 2250 1080 1086 1094 1415 0x40 0x9 connector 92: type DP-1, status: disconnected connector 99: type HDMI-A-1, status: disconnected connector 105: type DP-2, status: disconnected connector 110: type HDMI-A-2, status: disconnected connector 114: type DP-3, status: disconnected
(In reply to Jani Saarinen from comment #40) > If you have something like: > > Connector info > -------------- > connector 71: type DP-1, status: connected > name: > physical dimensions: 640x400mm > subpixel order: Unknown > CEA rev: 3 > DPCD rev: 12 > audio support: yes > DP branch device present: yes > Type: HDMI > ======> ID: 175IB0 > HW: 1.0 > SW: 7.32 > Max TMDS clock: 600000 kHz > Max bpc: 12 > > This is Parade Chip. > > > If you have like... > connector 95: type DP-1, status: connected > physical dimensions: 540x350mm > subpixel order: Unknown > CEA rev: 0 > DPCD rev: 12 > audio support: no > DP branch device present: yes > Type: HDMI > =====> ID: MC2800 > HW: 2.2 > SW: 1.77 > Max TMDS clock: 600000 kHz > Max bpc: 16 > HDCP version: HDCP1.4 > modes: > > This is MCA CRTC info --------- CRTC 48: pipe: A, active=yes, (size=1920x1080), dither=no, bpp=24 fb: 122, pos: 0x0, size: 1920x1080 encoder 85: type: DDI A, connectors: connector 86: type: eDP-1, status: connected, mode: "": 0 152840 1920 1968 2000 2250 1080 1086 1094 1132 0x0 0x9 cursor visible? no, position (0, 0), size 0x0, addr 0x00000000 num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0 --Plane id 31: type=PRI, crtc_pos= 0x 0, crtc_size=1920x1080, src_pos=0.0000x0.0000, src_size=1920.0000x1080.0000, format=XR24 little-endian (0x34325258), rotation=0 (0x00000001) --Plane id 38: type=OVL, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001) --Plane id 45: type=CUR, crtc_pos= 0x 0, crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000, format=N/A, rotation=0 (0x00000001) underrun reporting: cpu=yes pch=yes CRTC 66: pipe: B, active=no, (size=0x0), dither=no, bpp=0 underrun reporting: cpu=yes pch=yes CRTC 84: pipe: C, active=no, (size=0x0), dither=no, bpp=0 underrun reporting: cpu=yes pch=yes Connector info -------------- connector 86: type eDP-1, status: connected physical dimensions: 340x190mm subpixel order: Unknown CEA rev: 0 DPCD rev: 12 audio support: no fixed mode: "1920x1080": 60 152840 1920 1968 2000 2250 1080 1086 1094 1132 0x48 0x9 DP branch device present: no modes: "1920x1080": 60 152840 1920 1968 2000 2250 1080 1086 1094 1132 0x48 0x9 "1920x1080": 48 152840 1920 1968 2000 2250 1080 1086 1094 1415 0x40 0x9 connector 92: type DP-1, status: disconnected connector 99: type HDMI-A-1, status: disconnected connector 105: type DP-2, status: disconnected connector 110: type HDMI-A-2, status: disconnected connector 114: type DP-3, status: disconnected
You should get this with cat /sys/kernel/debug/dri/0/i915_display_info
This shows you have only eDP connected, not any external devices and no DP branch device present: no.
-- 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/203.
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.