Just to clarify to people here what exactly the mux is on Framework 16. It controls which GPU the eDP connects to. You really don’t want this exposed in the BIOS because hardcoding it to dGPU means your dGPU would never go into the lowest power state. Your battery life would be abysmal.
In Windows Radeon Software will let you set up policies that when you launch certain games it would automatically toggle the mux so that your dGPU spins up and eDP is connected to the dGPU. The whole thing is seamless on Windows.
The game (of course) runs on the dGPU. You end up with “less latency” than a regular hybrid graphics setup because you don’t make the round trip from one GPU to another to render content. The idea is supposed to be that when you have a very high refresh rate display (like 165Hz) that you can take full advantage of that.
In Linux this isn’t exposed today; and it’s mostly because of complexity. The kernel driver would in theory see hotplug events on both the iGPU and dGPU, but it wouldn’t be a pretty experience. You would see flickering because you would go through two modesets.
In Linux the DRM master (the compositor) is in full control of kernel mode setting. What would really need to happen is the system has to advertise a DRM property that it supports this mux switch and then the compositor would need to orchestrate the action to ensure that you don’t go through modesets.
Then lastly you would need a way for the compositor to advertise this ability to applications and the applications would need to opt in by using some compositor specific interface.
So like I said; a lot of complexity, a lot of projects would need to develop code and an architecture to support it.