So I recently bought the rx7700s dGPU for my 7040 Framework 16. However I was soon disappointed as I realized that it is not possible to switch the internal monitor to the dGPU in linux. While offloading applications via DRI_PRIME works good enough for most usecases, I was not satisfied with this.
Queue a few days of reading the source code of the EC and amdgpu driver and tinkering around.
Now I have a working tool that can switch the internal display between the iGPU and the dGPU at runtime.
It still needs work to prevent crashing the amdgpu driver in some situations, but I expect it to be good enough for the public in a few days.
However before I let other people try it, it would be great if someone from framework could verify if what I’m doing is safe for the device.
WARNING: DO NOT TRY REPLICATING THIS WITHOUT UNDERSTANDING WHAT IT DOES. IT MIGHT DAMAGE YOUR DEVICE. IT WILL CAUSE THE amdgpu DRIVER TO CRASH OR BUG OUT.
I will omit details and additionally required steps for now since I don’t want to encourage careless tinkering. Be assured that this is not an attempt to keep this secret for personal gain. I will publish it as open source once it is stable and I know it won’t damage the hardware.
So here is the question for the framework team:
My current method hinges on directly controlling the GPIOs of the EC to put the MUX into reset, switch it to the other port and releasing the reset, waiting 100ms between each step.
Is this safe for the hardware? Any risk of damaging components?
In the meantime it would be helpful to collect a few more samples from other people that have a Framework 16 with a dGPU. If you want to help me make sure the tool will work in other configurations, please post the following information:
Which Mainboard/CPU you have
Which dGPU you have
Your Linux distribution with Version
The output of the following commands:
uname -a
cat /etc/os-release
lspci | grep VGA
find /sys/devices -name "edid"
sudo find /sys/kernel/debug/dri -name "*eDP*" (This one might fail on some distributions.)
You can omit some of the information if you want for privacy reasons. In this case please replace them with “[redacted]” and add some information on what you removed.
Since the tool heavily relies on assumptions I made based on my exact device and OS, this will allow me to verify some details for different setups.
I don’t know if my approach also works for nvidia dGPU since I have no way to test it right now. But I’ll be happy to take a look at it. Maybe my approach is more generic than I assume right now.
I don’t know how you have implemented your tool, but I suspect that to make it more robust you’ll want to hook into udev in some way.
CPU: AMD Ryzen 7 7840HS
dGPU: AMD Radeon RX 7700S
uname: Linux hipparchus 7.0.3 #1-NixOS SMP PREEMPT_DYNAMIC Thu Apr 30 09:13:05 UTC 2026 x86_64 GNU/Linux (yes I know my kernel is out-of-date; I blame nixpkgs for not updating their stuff correctly)
Thank you for the links. Unfortunately they are not helpful to me right now.
The supergfxctl only supports power management and offloading. MUX control is only possible with reboots in that implementation. Controlling the MUX is surprisingly not the hard part (assuming what I’m doing won’t damage anything). It’s everything else that needs to be done so the driver doesn’t freak out when I “disconnect” the panel from one GPU and to make sure it gets detected on the other GPU.
And I’ve seen the work about SmartMux that happened in the linux kernel. I’m not that good of a programmer and I won’t even pretend to really understand what they did there. But it only looks like basic scaffolding that is needed for a full implementation later on.