On Mon, Jun 16, 2025 at 10:05:48AM -0500, Daniel Dadap wrote: > On Sat, Jun 14, 2025 at 09:04:52AM +0200, Lukas Wunner wrote: > > On Fri, Jun 13, 2025 at 04:47:20PM -0500, Daniel Dadap wrote: > > > Ideally we'd be able to actually query which GPU is connected to > > > the panel at the time we're making this determination, but I don't > > > think there's a uniform way to do this at the moment. Selecting the > > > integrated GPU seems like a reasonable heuristic, since I'm not > > > aware of any systems where the internal panel defaults to dGPU > > > connection, since that would defeat the purpose of having a hybrid > > > GPU system in the first place > > > > Intel-based dual-GPU MacBook Pros boot with the panel switched to the > > dGPU by default. This is done for Windows compatibility because Apple > > never bothered to implement dynamic GPU switching on Windows. > > > > The boot firmware can be told to switch the panel to the iGPU via an > > EFI variable, but that's not something the kernel can or should depend on. > > > > MacBook Pros introduced since 2013/2014 hide the iGPU if the panel is > > switched to the dGPU on boot, but the kernel is now unhiding it since > > 71e49eccdca6. > > This is good to know. Is vga_switcheroo initialized by the time the code > in this patch runs? If so, maybe we should query switcheroo to determine > the GPU which is connected to the panel and favor that one, then fall > back to the "iGPU is probably right" heuristic otherwise. Right now vga_switcheroo doesn't seem to provide a function to query the current mux state. The driver for the mux on MacBook Pros, apple_gmux.c, can be modular, so may be loaded fairly late. Personally I'm booting my MacBook Pro via EFI, so the GPU in use is whatever efifb is talking to. However it is possible to boot these machines in a legacy CSM mode and I don't know what the situation looks like in that case. Thanks, Lukas
