Use of USB port on GPU Expansion Module

Framework Laptop 16
12

Just a minor update. on my progress using the port in the back of the 7700s

I managed to get the USB-C cable that came with my Dell monitor (provides power delivery and USB-C connection) to my MacBookPro to work with my LG 5k.

The dell cable supports Alternate mode with DP1.2, USB
3.1 upstream port ,Power Delivery PD up to 45W

This allowed the LG to display in 5k.

The thunderbolt cable that came with the LG would not work and only allowed 1024 x 720 and a blank screen, the monitor would complain of an incorrect DP version.

Nor did a USB-C to Display port cable work.

2 Likes
13

I’ve been using one of these for a couple of years with both my MacBook Pro and the work laptop : 4K USB C to DisplayPort adapter cable with break-proof metal connectors – 2m (supports 4K video/60Hz from notebooks/smartphones to large screens – DP, USB 3.1, Type C, Thunderbolt 3) by CableDirect: Amazon.co.uk: Computers & Accessories

Works fine with the FW16, when tested over the weekend on either the Expansion card USB-C ports or the dGPU port.

14

This is going to sound stupid - but did you try and reboot the laptop with the cable (that wasn’t working) plugged into the back?

I have a little adapter that I use - and when I first plugged it in, it wouldn’t allow me to activate the monitor (on Fedora).

After a reboot, my second display is up and running.

Just a thought in case someone else sees a similar issue.

1 Like
15

I have a dock and I tried connection to both USB C on side and the rear port on the graphics unit it will not activate my monitor. Any thoughts

16

I suspect the dGPU was off and didn’t wake up “from the plug in”. This is normal. You can wake it up by running lspci, nvtop, or reading sysfs files from it like sensor data. Then you wouldn’t need to reboot.

2 Likes
17

If it happens again, Ill have to try that - I had already been running games when I was trying the first time so maybe it had gone to idle.

18

I’d love to use the dGPU’s DP video out, but unsure if I need to buy a cable or if I can just plug my DP module into it?

I thought I’d try the module (got 2) and had some mixed success…

  • intermittently worked after a reboot, would not work if plugged in after booted up
  • by intermittently I mean SDDM would never launch driving both the laptop display and external monitor… post login would either bring a successful load with two displays, or would fail and dump be back to SDDM

With DP connected to the side (a second dp module), SDDM always loads with two screen (iGPU).

So either:

  • I should be able to use the DP module attached to the dGPU, but I have a bad one, or
  • I need to go buy a USB-C to DP cable to properly driver my monitor
19

You need to turn the dGPU on for the port to work after boot because the dGPU turns off when idle.
Open any GPU monitoring software (nvtop or mission center are examples), run lspci or read sysfs files for it.

20

Hi Mario,

I’m not sure I understand. Are you saying that whether I use the FW DP module or buy a USB-C to DP cable to connect a monitor to the dedicated dGPU USB-C port… the dGPU won’t care that it has a monitor plugged into it and go to sleep during the boot process so my external monitor will be blank before/during SDDM login (pre desktop)?

Why is the dGPU idle if I have a monitor connected to its dedicated display port? In my experience, a monitor connected to video card = you have work to do, show me an image, not go to sleep.

In a design where the only purpose for the dGPU is to be optionally used to drive the laptop panel instead of the iGPU… then sleeping the dGPU when not in use makes sense in an “on battery” use case (and not a bad option either for an “on AC, off battery” use case)… but the moment a dedicated port is added to the dGPU, the use case scenarios must be expanded:

Scenario #1 - On battery, external display on dGPU port, iGPU defaults to laptop panel
Monitor connected to dGPU port = stay awake. If I chose to keep the external monitor connected while on battery, then I accepted the expected increased power drain on the battery.

Scenario #2 - On AC, external display on dGPU port, iGPU defaults to laptop panel
If I am connected to AC (no battery drain)… why sleep the dGPU? If energy conservation is a concern, then they could always move the external monitor to one of the side DP/HDMI ports and that is covered by Scenario #4

Monitor connected to dGPU port = stay awake

Scenario #3 - On battery, dGPU port empty, iGPU defaults to laptop panel
Sleeping the dGPU makes sense here as there is no external monitor connected to the dGPU and the iGPU will driving the laptop panel.

If the user swaps in the dGPU to drive the laptop panel on battery, then they accept the expected increased power drain.

No monitor connected to dGPU port = sleep; until user wants panel/app driven by dGPU

Scenario #4 - On AC, dGPU port empty, iGPU defaults to laptop panel
Similar to Scenario #2… If I am connected to AC (no battery drain)… why sleep the dGPU? But like Scenario #3 there is no monitor connected on the dGPU port, so putting the dGPU to sleep is alright as the panel is driven by the iGPU, until the user chooses to swap the dGPU in to drive the laptop panel.

No monitor connected to dGPU port = sleep; until user wants panel/app driven by dGPU

Another Thought
I wonder why there isn’t a BIOS option to disable the iGPU in favor of the dGPU; thereby killing the sleep mechanism so it acts like a dedicated GPU.

Potential Work-a-rounds?
Is there a…

  1. kernel parameter I can add to GRUB,
  2. module I can add to mkintcpio/initramfs,
  3. conf file I can add to /etc/modprobe.d,
  4. or service i can add to systemd

…that will keep the dGPU awake if I have a monitor plugged to to directly? or if not, an override for the 5 second sleep entirely?

21

You can change the coarse behavior of runtime power management using amdgpu.runpm= and a number on the kernel command line.

Here is the documentation explaining what numbers do what:

https://www.kernel.org/doc/html/v6.9-rc1/gpu/amdgpu/module-parameters.html

I suggest you check whether the dGPU is suspended in any situations you don’t expect it to be. You can check from the sysfs file.

Granualar policy on other events like battery vs AC is typically not set up by the kernel. This responsibility is for userspace.

You can set up udev rules or other software to change the power/control sysfs file for the dGPU to always be on when you’re connected to AC for example if that is the policy you desire.

22

That’s awesome, as I found and tried that this morning…

GRUB_CMDLINE_LINUX_DEFAULT="udev.log_priority=3 amdgpu.runpm=0 sysrq_always_enabled=1"

but wasn’t sure it was working since when the boot process reached SDDM login, my external monitor connected to the dgpu was still blank.

Thinking it might help, I also added the amdgpu to the modules section of mkinitcpio.conf…
MODULES=(amdgpu)

Good news so far is that once in the kde desktop (post login), monitoring power_status seems to be sticking at D0 (no more D3cold)

cat /sys/class/drm/card1/device/power_state
D0

Maybe I’m making an incorrect assumption… or am looking down the wrong path… when boot reaches SDDM (pre desktop), should the external monitor connected to the dGPU also be displaying SDDM login prompt?

  • If so, where should I be looking to work towards making this happen?
  • If not, would you happen to know why not?
23

Try keeping the lid closed when you get to the login screen. I would suspect it will display there then.

24

Unfortunately not. I tried two paths:

  1. reboot, reach SDDM, close laptop… external monitor on dGPU stayed blank
  2. reboot, close lid, wait a minute, external monitor stayed blank, lifted lid and confirmed at SDDM

I’m starting to think it may have something to do with not having any conf files (like /etc/X11/xorg.conf or /etc/X11/xorg.conf.d/10-monitor.conf that provide some kind of hints that there is a large screen (virtual screen?) spread across two monitors at SDDM.

Post SDDM, kscreen kicks in, puts them together, and voila, two monitors display. If I log out at this point, SDDM is is displayed on both monitors because xrandr has already been setup by kscreen… so I think I need to figure out how to do what kscreen did with xrandr pre KDE.

I’m reading two sources to see if I can figure this out:

  1. Xorg - ArchWiki
  2. Multihead - ArchWiki

What xrandr displays once on the desktop; my target for SDDM on boot:

xrandr                                                                                                                                ✔ 
Screen 0: minimum 320 x 200, current 4240 x 1440, maximum 16384 x 16384
eDP-1 connected 1680x1050+2560+390 (normal left inverted right x axis y axis) 345mm x 215mm
   2560x1600    165.00 +  60.00 +
   1920x1200    165.00  
   1920x1080    165.00  
   1600x1200    165.00  
   1680x1050    165.00* 
   1280x1024    165.00  
   1440x900     165.00  
   1280x800     165.00  
   1280x720     165.00  
   1024x768     165.00  
   800x600      165.00  
   640x480      165.00  
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
DisplayPort-3 disconnected (normal left inverted right x axis y axis)
DisplayPort-4 disconnected (normal left inverted right x axis y axis)
DisplayPort-5 disconnected (normal left inverted right x axis y axis)
DisplayPort-6 disconnected (normal left inverted right x axis y axis)
DisplayPort-7 disconnected (normal left inverted right x axis y axis)
DisplayPort-8 disconnected (normal left inverted right x axis y axis)
eDP-1-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 697mm x 392mm
   2560x1440    144.00*+ 120.04    96.02    72.02    60.00    50.01    48.01   120.00    99.95    59.95  
   1920x1200    144.00  
   1920x1080    120.00   100.00   119.88    60.00    50.00    59.94  
   1600x1200    144.00  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.89  
   1280x800      59.81  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08
25

Does sddm run on Wayland? If so X conffiles won’t do anything.

I think you should post somewhere KDE specific, forum or bug tracker to discuss your behavior and go over SDDM verbose logs to make sense of the behavior.

Fwiw both gdm and Windows login screen doesn’t show login screen on multiple displays. Its only whatever is considered “primary”.

1 Like
26

well, and that could be part of the problem… my desktop experience with Windows and Linux (expectation) has been with one dGPU (no iGPU) driving two monitors. If I connect my DP cable to a FW16 side module, the monitors act like I’d expect showing SDDM on 2 displays; because they’re both connected to iGPU in that state.

So, I think the lesson I learned here is… I’ll only see a login prompt on the primary (iGPU) monitor when I’m connecting my DP cable to the dGPU port.

Thank you for pointing out amdgpu.runpm, that was important to learn.

P.S. I’m focusing on Xorg as wayland had some butchering performance on a couple games i like to play, so no wayland for me at this point in time.

27

well I’ll be… just as I’d resolved to leave things as they are, I stumbled into the solution as I was shutting down browser tabs and found something I hadn’t tried.

Just thought I’d share this here as anyone using SDDM may want to know this… and interestingly I learned SDDM always starts in X11, regardless if you’ll select a wayland desktop session or x11

Per SDDM - ArchWiki, I did the following:

  1. Launched xrander on the KDE desktop so I could get my current multi-monitor (1 iGPU & 1 dGPU connected) settings
xrandr | grep -w connected
eDP-1 connected 1680x1050+2560+390 (normal left inverted right x axis y axis) 345mm x 215mm
DisplayPort-1-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 697mm x 392mm
  1. Then added two lines to /usr/share/sddm/scripts/Xsetup below the default two rem’d lines
#!/bin/sh
# Xsetup - run as root before the login dialog appears

xrandr --output DisplayPort-1-0 --auto --primary
xrandr --output eDP-1 --right-of DisplayPort-1-0 --auto --noprimary
  1. Rebooted, and voila! SDDM was displaying on both monitors

An interesting side effect is that the transition to the KDE desktop was much quicker, and the “gear” (thinking) screen was pretty much non-existant; I figure because both displays were already initialized/available by X11.

Note: I am also going to consider the previous changes I made as part of the solution…

2 Likes
28

Hmm, I think I celebrated too early. Everything I did above worked great; so long as I kept the DP port connected monitor set to the left in the display orientation of KDE. The moment I switched the DP monitor to the right of the laptop; chaos ensued.

I started another thread on this phenomenon @ Swapped position of FW16 & dGPU DP displays in KDE (X11), now steam games launch "confused", but thought I’d post here after I discovered a second scenario that strengthened my growing sense that using the dGPU port to drive a monitor also requires it to be set to the left-most monitor.

The short version (will keep the details about what a “confused game” and the “invisible line” means in the other thread):

  1. DP monitor direct connected to dGPU, orientation set so that monitor is on the left of the laptop, games play beautifully. settings as previously posted
  2. Moved laptop from table to desk, swapped orientation of monitors physically and in kde settings so the DP (still connected to dGPU) is on the right. launched game and it opens on the wrong monitor and introduces the “invisible line”. Reversing my /usr/share/sddm/scripts/Xsetup did not correct the behavior… but reversing the left/right monitors in KDE display orientation did correct the behaviour… direct connected dGPU monitor set to the left in KDE
  3. Moved the DP monitor to the side iGPU DP connection. Set KDE orientation so DP monitor is on the right (matching physical orientation). Removed /usr/share/sddm/scripts/Xsetup settings (not needed with SDDM using the iGPU). Rebooted and games behave properly; loading on the DP monitor (primary display in KDE) and no “invisible line”… and stayed true even if I swapped orientations between left and right inside KDE settings.

All scenarios above suggest:

  • When an external monitor is direct connected to the dGPU, set it’s orientation as the left monitor or problems will occur in games
  • When an external monitor is connected to the iGPU, set whatever orientation you want, there will be no problems.

------- Update -------
I think it is also important to note that this is while booted into a KDE X11 session. If I log out and launch KDE wayland the “windowed” game behaves properly, but a fullscreen game crashed xwayland… and so I stick to x11 where my game at least all launch.

------- Update 2 -------
I think I figured out another important detail… some steam games have a native linux version whereas many require PROTON to allow windows games to run on Linux. The two games focused on in my writings were not Linux native games, so PROTON / VULKAN / etc is involved. Launched a 3rd windowed game that has a Linux native version, and it launched/behaved properly.

29

I got it working ironically by not using the LG display USB C cable but using the Cable from my Dell 27 inch monitor

30

I picked up a USB-C to DP cable online @ https://www.amazon.ca/Cable-Matters-DisplayPort-USB-C-Supporting/dp/B01J6DT070

But I’m getting the same results as when trying to use the DP module.

31

I’m having issues on Windows trying to connect to my LG G2 OLED TV

Using this adapter:

Using this cable:
https://www.amazon.co.uk/dp/B08TM8TW1R?psc=1&ref=ppx_yo2ov_dt_b_product_details

I get a 4k output however VRR, HDR & 120Hz won’t work
Any ideas?