[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<MA0P287MB02171286CB1BF5CD506FCE55B8A32@MA0P287MB0217.INDP287.PROD.OUTLOOK.COM>
Date: Wed, 17 Jul 2024 16:52:51 +0000
From: Aditya Garg <gargaditya08@...e.com>
To: Ard Biesheuvel <ardb@...nel.org>
CC: "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Hans de Goede
<hdegoede@...hat.com>, Lukas Wunner <lukas@...ner.de>, Kerem Karabay
<kekrby@...il.com>, Orlando Chamberlain <orlandoch.dev@...il.com>,
"sharpenedblade@...ton.me" <sharpenedblade@...ton.me>
Subject: Re: [PATCH v3 0/2] efi/x86: Call set_os() protocol on dual GPU Macs
Hi Ard
> Hi,
>
> Is this a theoretical concern? Or are you aware of any user that is
> actually affected by this?
We had a Mac Mini user who wasn't able to use hybrid graphics
on his Mac after using the eGPU. So no, it's not a theoretical concern
> In any case, given the niche nature, enabling this more widely by
> default does not seem like a great approach, as the risk for
> regressions outweighs the benefit.
>
> I could imagine the use of a EFI variable to opt into this, would that
> work? It would have to be set only once from user space (using
> efivarfs)
I'm not really sure about efivars here, but am ready to test. As long as
it doesn't break booting of macOS or Windows, I don't find it an issue.
macOS may also reset the variable, again have to verify by testing the same.
I guess it will also get reset if a users resets their NVRAM.
Powered by blists - more mailing lists