@DaveWK
I don’t know which monitor you have, but if it has a usb-c video in connection, it probably has the equivalent of a USB-C->DP->HDMI adapter inside the monitor.
@Matt_Hartley I think you should probably add something about this to your documentation about how the GPU is in D3cold when not in use and that to use a monitor you need to wake it up. Maybe you can list a few ways to wake it up (Like Mission Center or sensors software, lspci, etc).
Could you double check the DE display panels don’t actually wake it? Start out with nothing plugged in, display should be in D3. Plug something in and verify it doesn’t work.
Then go into either GNOME or KDE (whichever you use) display panel and see if the display starts to light up. I don’t expect it does; but I would love to be surprised. If it doesn’t, would you mind filing a bug with those projects and drop a link here?
GNOME bugs would go here: GNOME / Settings · GitLab
KDE bugs would go here: KDE Bugtracking System Main Page
2 Likes
The situation has become more complicated. I went to double verify like you asked but found the solution to be unreliable and actually causes my system to partially lock up.
This is what I’ve discovered. I’m not sure how verbose to be here, let me know how I can best share this information to be of the most use.
Steps to reproduce from cold boot:
- Connect Framework HDMI expansion card to dGPU directly and connect HDMI cable to external monitor.
- Open a terminal and run
lspci.
This consistently results in the following symptoms for me:
- Terminal command hangs and produces no output, while also not canceling the command when ctrl+c is pressed.
- Laptop power consumption spikes (as measured with an AC power meter that I always have the charger plugged into).
- Fans ramp up dramatically after short delay expelling heat that can easily be felt when reaching behind the laptop to the dGPU heat vents.
- No other windows or applications will open. System doesn’t respond to suspend, log off, or reboot commands from GUI.
systemctl rebootin a terminal also hangs with no output or effect even when left for an extended period of time.
Only way I found to restore functionality is to hold power button to force system power off and boot back up.
This does NOT happen when following the exact same steps with the Framework DP expansion card. With the DP card connected to an external display the monitor remains dark until the display options panel is opened using the settings GUI and then the monitor lights up and properly functions as @Mario_Limonciello suggested should happen.
1 Like
Well it’s good news to hear that opening the display settings panel does cause it to light up with the DP card. Is this GNOME or KDE?
However with that HDMI card that’s pretty surprising. Ther can be problems anywhere in the stack, but the first thing I would start with is if the F/W is up to date on the HDMI card.
Next I would check if you can reproduce a similar result with iGPU and this card too. If it’s only dGPU, does it happen on cold boot or only with hotplug and wake GPU?
Any interesting logs from when it happened?
A portable monitor makes things a bit more tricky, i noticed that when i connect my portable monitor over a single usb-c, it would not power up quickly enough to get detected at startup of my DE. Hence the DE would not extend the workspace to it, hence the dGPU would power down…
So i had to power it separately during boot, and after that I can remove the 2nd cable once the DE is running…
Not the most convenient, but it works…
What is the particular reason to use the usb-c connection on the back of the 7700 ?
The same signal from the 7700 is also fed to the side expansion slots, so why not use them?
Usb-c hdmi alt mode in is incredibly rare/non existent, if your display has a usb-c display in that’s pretty much guaranteed to be displayport.
1 Like
I don’t believe that is the case, as far as I understand, the signal from the iGPU is on the side expansion slots, and only by using specific driver support and by setting an environment variable you can get the dGPU to kick in, and then still, the output goes through the iGPU.
In some scenario’s when you wish to use the dGPU directly, you can hook up your monitor to the 7700s on the back, e.g. when you wish to run a VM with GPU passthrough, or when you wish to attach more screens than the iGPU supports.
There may be a mux inside, allowing switching, but the API to that does not seem to be exposed, so you can’t manually switch, meaning it will only switch when the driver sees fit to do so.
Even if the mux was exposed it would only change the eDP.
While this is not the most amazing workaround, if your goal is to have USB-C to HDMI/DP/Whatever work when plugged into the port directly connected to the dGPU, this is what I use.
First, we’re using nvtop as our method of “waking up” the dGPU from D3cold. Install it.
On Fedora/Ubuntu/and any other distro:
- Create a script with the following:
#!/bin/bash
echo "USB device connected. Running nvtop for 2 seconds."
timeout 2 nvtop
echo "nvtop run completed."
-
Save it as /usr/local/bin/external_video.sh
-
Setup a udev rule to make this work:
sudo nano /etc/udev/rules.d/99-external_video.rules
- In the rule:
ACTION=="add", SUBSYSTEM=="usb", RUN+="/usr/local/bin/external_video.sh"
- Save the file. Run:
sudo udevadm control --reload-rules
then
sudo udevadm trigger
This the approach I use on my own Framework Laptop 16.
Now plug in the USB-C to HDMI/DP/Whatever into your dGPU port.
- What this does:
- This will run nvtop for a couple of seconds then close it anytime anything USB related is plugged in.
- Requires nvtop to be installed to act as our method of dealing with D3cold behavior. Again, D3cold is doing its job correctly, we’re just providing a tool to surpass it.
- Alternatives to this:
- Installing Mission Center or lspci or using other methods to bring the dGPU out of D3cold.
A simpler method is to just cat one of the dGPU sysfs files for such a workaround.
But it was mentioned above opening the display setting panel in the DE does it too, that’s worth trying to stay away from command line.
1 Like
Ah, fair. 
- I may touch on this again with that method again later this week.
Hm, if I am reading this right. USB-C to dGPU in the back, open up display setting panel in the DE brings it the connected display? I did not experience this at all in GNOME. I’ll have to dig into that deeper.
I’ve never tried myself. But it was an assertion in one of the threads that it worked.
1 Like
Is there something a little bit less “side-effect-y” to poke the device out of D3cold? Ideally I could set some rule to block/mask the GPU from going into D3cold and not depend on a side effect of running nvtop or lspci and just use whatever codepath that those utilities use.
You can turn off runtime PM for the dGPU; but as a warning this is going to burn battery pretty hard.
Here’s how to do it:
3.6. Runtime Device Power Management | Red Hat Product Documentation
And you don’t need to specifically use those tools to cause an exit; reading a sysfs file for the dGPU or even reading sensor data using sensors will cause it to exit too.
2 Likes
thanks! that autosuspend_delay_ms param looks a bit less reckless to start testing on – my hunch is that it’s set too low and is sleeping before the connected monitor wakes up completely.
@Mario_Limonciello @Matt_Hartley I actually had this exact thing happen to me.
Slight difference is that I do not have an HDMI or DP expansion card. I have a small USB C dock plugged to the back of the dGPU.
Running sensors, nvtop, btop, lspci, etc locks up the entire laptop.
That being said. I have also tried the following:
- Nothing plugged in
- Run lspci, nvtop, etc (even tried starting a game from steam that used dGPU)
- Plug in the USB C hub w/hdmi cord to the back of the dGPU
- Nothing happens (game won’t launch either
- Run lspci, nvtop, etc etc etc - confirm it hangs
5a. Unplug the USB C dock and cross my fingers (still nothing) - Hard reboot to restore function of the laptop.
I checked journalctl logs and can’t see anything that might help - but can upload them if wanted? Running F40 btw (6.8.11 kernel as 6.9 has a bug)