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.
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?
reboot, reach SDDM, close laptop… external monitor on dGPU stayed blank
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:
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”.
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
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
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
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…
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.
The short version (will keep the details about what a “confused game” and the “invisible line” means in the other thread):
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
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
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.