Triple display issues

Ask Fedora Ask in English
,
1

Hardware: ThinkPad T14s Gen1 (Intel 10th Gen) and Lenovo Ultra Dock connected via dual USB-C.
Software: Fedora 37 with Gnome Wayland

The ThinkPad has a 4K display, in addition there is an external 3840x1600 display connected to the dock via DP. This works fine.

Today, I tried to connect yet another 3840x1600 display as the 3rd display via DP to the dock. The newly added display did not get a signal and the ThinkPads own display was half black on the right-hand side of the display. I tried also connecting it via HDMI and USB-C to the dock but it did not really matter.
Disabling the ThinkPad internal display in Gnome also did not help. The display would remain ON, showing a black screen with just a cursor, and the extra display would not get a signal.

I then tried a newer ThinkPad T14s Gen2 (Intel 11th Gen) on the same Dock, running current Ubuntu (Wayland), and all 3 displays worked straight away.

Lastly, I tried an older ThinkPad T490s (Intel 8th Gen) on the Dock, running Win10, and again all 3 displays worked straight away.

I then tried a different 2560x1440 display as the 3rd display, again DP connected, with the original ThinkPad T14s Gen1. This time all 3 displays worked. But on the ThinkPad integrated display roughly 1cm of display space on the right-side was not usable (black with a fragment of the Gnome Top Bar).
I then rotated the 3rd display into portrait mode and updated Gnome, and the issue with the ThinkPad display was gone.

It therefore seems there is some maximum display width issue with this particular combination of hardware and software?

  • 3840+3840+3840 = 11520 pixels in width would not work
  • 3840+3840+2560 = 10240 pixels in width works partly (display issues on the integrated LCD)
  • 3840+3840+1440 = 9120 pixels in width works

One last issue I found, is that with a rotated display, having Chrome windows on both the regular and rotated display worked for a bit, but at some point the mouse cursor got rotated 90 degrees, but only when hovering over Chrome windows.

Are these known issues?

2

I’m neither using Gnome, nor have a total display area that wide, so I can’t be sure.
But I would be very surprised if the problem with very high total width were in Gnome.
I would bet most of your issues are in the display driver for your Intel UHD Graphics. IIUC, it uses shared memory, so there may be some pre-boot (BIOS) setting needed to let it take enough memory for your display configuration.

I think you ought to gather and post various info about the display adapter and driver and ram mapping in order that you can get a better answer from someone who knows more about it than I do. I would use lspci for display adapter basic info. Without experimenting, I don’t recall where you should look for good info on the display adapter and ram mapping.

BTW, my own displays are two 1620x2880 portrait plus one 3840x2160 landscape, but because the 3rd is physically much larger, I have it scaled (through wayland) to look like 4518x1906 to the application level (and I think to KDE as well).

If I were investigating issues with a shared memory graphics driver, one thing I would look at is dmesg | grep RAM
It is outside my experience, so I’m not sure that is a useful place to look and if I looked, I’d then need to research the meaning of the output (if it is even relevant). But until/unless someone gives you better places to look, I suggest that.

3

Based on my testing, it seems to have problems around 10000 pixels in width.

In the BIOS there is indeed an option Config → Display → Total Graphics Memory

This drop-down menu provides two options, 256MB or 512MB. I already had that set to 512MB.

$ sudo lspci -vvd 8086:9b41
00:02.0 VGA compatible controller: Intel Corporation CometLake-U GT2 [UHD Graphics] (rev 02) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device 22af
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 143
	IOMMU group: 0
	Region 0: Memory at e9000000 (64-bit, non-prefetchable) [size=16M]
	Region 2: Memory at a0000000 (64-bit, prefetchable) [size=512M]
	Region 4: I/O ports at 4000 [size=64]
	Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
	Capabilities: [40] Vendor Specific Information: Len=0c <?>
	Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- RBE+ FLReset+
		DevCtl:	CorrErr- NonFatalErr- FatalErr- UnsupReq-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
		DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR-
			 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
			 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
			 FRS-
			 AtomicOpsCap: 32bit- 64bit- 128bitCAS-
		DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled,
			 AtomicOpsCtl: ReqEn-
	Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
		Address: fee00018  Data: 0000
	Capabilities: [d0] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [100 v1] Process Address Space ID (PASID)
		PASIDCap: Exec- Priv-, Max PASID Width: 14
		PASIDCtl: Enable- Exec- Priv-
	Capabilities: [200 v1] Address Translation Service (ATS)
		ATSCap:	Invalidate Queue Depth: 00
		ATSCtl:	Enable+, Smallest Translation Unit: 00
	Capabilities: [300 v1] Page Request Interface (PRI)
		PRICtl: Enable- Reset-
		PRISta: RF- UPRGI- Stopped+
		Page Request Capacity: 00008000, Page Request Allocation: 00000000
	Kernel driver in use: i915
	Kernel modules: i915

As you can see, region 2 is indeed 512MB.

$ dmesg|grep "i915\|drm"
[    1.424854] ACPI: bus type drm_connector registered
[    1.448483] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
[    1.451606] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    3.352897] i915 0000:00:02.0: enabling device (0006 -> 0007)
[    3.353546] i915 0000:00:02.0: [drm] VT-d active for gfx access
[    3.369476] i915 0000:00:02.0: vgaarb: deactivate vga console
[    3.369535] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[    3.370253] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=mem
[    3.372201] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4)
[    5.726285] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 1
[    5.773458] fbcon: i915drmfb (fb0) is primary device
[    5.773463] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[   14.184345] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
[   15.018914] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915])
[   15.208409] sof-audio-pci-intel-cnl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
1 Like
4

FYI… A colleague tested the triple display (>10k pixels) setup on another T14s Gen1 (Intel 10th Gen) running current Arch with KDE. And he was having tons of problems. Major glitching such as flashing displays and corruption. He never got more than 1 external display working.

5

One thing that may help is you might have a setting in your BIOS to allocate more memory to the integrated graphics. I’ve seen this happen in multi-display setups where the iGPU memory gets exceeded and it just blacks out the canvas at some point and glitches out the rest. Otherwise, the other unfortunate reality is that DisplayPort versions supported over USB-C is an absolute mess, and often there is a sacrifice to resolutions and refresh rates for adding further displays through it (sometimes switchable in BIOS). Additionally, I’ve had some cases where a newer HDMI cable got it to work or using a DP instead of HDMI (or vice versa). Again, this is unfortunately a pretty common story right now across vendors and operating systems as there is just so much variation between vendors, docks, monitor, USB-C (with or without thunderbolt and what version) and cable specs at the moment.

6

Thank you. But as mentioned, the BIOS is already set to the maximum amount of video RAM allocation.

And it does work on an older ThinkPad running Win10, and a newer ThinkPad running current Ubuntu. An identical ThinkPad running current Arch with KDE had even more problems, but I attribute that to Gnome having better Wayland support.

7

I moved an extra monitor over to test something else (which failed). But while it was here, I tried a layout with total width 12160. I’m not seeing any problems.
I’m using KDE/Wayland.

image

The 85% on the Mars-Tech means some levels of the software see even wider (3840 / .85 = 4517 pixels) for that display. But I’m not counting that in the 12160 width.

I don’t have gnome installed on this system. But I really doubt the original issue was in gnome (I still think card specific display driver issue).