From: Lukas Wunner <lukas@wunner.de>
To: Daniel Dadap <ddadap@nvidia.com>
Cc: Mario Limonciello <superm1@kernel.org>,
Bjorn Helgaas <helgaas@kernel.org>,
Alex Williamson <alex.williamson@redhat.com>,
mario.limonciello@amd.com, bhelgaas@google.com,
Thomas Zimmermann <tzimmermann@suse.de>,
linux-pci@vger.kernel.org, Hans de Goede <hansg@kernel.org>
Subject: Re: [PATCH] PCI/VGA: Look at all PCI display devices in VGA arbiter
Date: Sat, 14 Jun 2025 09:04:52 +0200 [thread overview]
Message-ID: <aE0fFIxCmauAHtNM@wunner.de> (raw)
In-Reply-To: <aEycaB9Hq5ZLMVaO@ddadap-lakeline.nvidia.com>
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.
I don't pretend to fully understand the consequences of the proposed
patch, just want to highlight the regression potential on Apple machines
and probably others.
Thanks,
Lukas
next prev parent reply other threads:[~2025-06-14 7:14 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-13 3:12 [PATCH] PCI/VGA: Look at all PCI display devices in VGA arbiter Mario Limonciello
2025-06-13 19:07 ` Bjorn Helgaas
2025-06-13 19:31 ` Mario Limonciello
2025-06-13 20:31 ` Bjorn Helgaas
2025-06-13 20:56 ` Mario Limonciello
2025-06-13 21:47 ` Daniel Dadap
2025-06-14 7:04 ` Lukas Wunner [this message]
2025-06-16 15:05 ` Daniel Dadap
2025-06-16 19:14 ` Lukas Wunner
2025-06-17 15:53 ` Daniel Dadap
2025-06-17 16:06 ` Mario Limonciello
2025-06-17 16:36 ` Daniel Dadap
2025-06-17 17:01 ` Mario Limonciello
2025-06-13 21:19 ` Alex Williamson
2025-06-13 21:29 ` Mario Limonciello
2025-06-16 6:42 ` Thomas Zimmermann
2025-06-16 6:50 ` David Airlie
2025-06-16 7:21 ` Thomas Zimmermann
2025-06-16 7:24 ` David Airlie
2025-06-16 9:11 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aE0fFIxCmauAHtNM@wunner.de \
--to=lukas@wunner.de \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=ddadap@nvidia.com \
--cc=hansg@kernel.org \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=superm1@kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.