Use of USB port on GPU Expansion Module

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.

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?

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

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  

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

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.

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

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.

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