> On 30 Jun 2024, at 4:35 PM, Orlando Chamberlain <orlandoch.dev@xxxxxxxxx> wrote: > > On Sun, 30 Jun 2024 at 20:50, Aditya Garg <gargaditya08@xxxxxxxx> wrote: >> >> >> >>>> On 30 Jun 2024, at 3:32 PM, Lukas Wunner <lukas@xxxxxxxxx> wrote: >>> >>> On Sun, Jun 30, 2024 at 09:13:33AM +0000, Aditya Garg wrote: >>>>>> On 30 Jun 2024, at 1:34 PM, Lukas Wunner <lukas@xxxxxxxxx> wrote: >>>>> On Sun, Jun 30, 2024 at 04:42:55AM +0000, Aditya Garg wrote: >>>>>> Based on this patch for GRUB by Andreas Heider <andreas@xxxxxxxxx>: >>>>>> https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html >>>>> >>>>> Please include his Signed-off-by and cc him. >>>> >>>> Not sure about this since the patch was send to grub and not lkml, >>>> and his work has been used without informing him for this patch solely >>>> on the basis of GPL. >>>> >>>> I've always been confused in signed-off-by in case of authors whose work >>>> has been used without their explicit consent just because the license >>>> permits it. >>>> >>>> Should I still add his signed-off-by? >>> >>> I would. >>> >>> >>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt >>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>>>>> @@ -399,6 +399,8 @@ >>>>>> useful so that a dump capture kernel won't be >>>>>> shot down by NMI >>>>>> >>>>>> + apple_set_os [KNL] Report that macOS is being booted to the firmware >>>>>> + >>>>> >>>>> Why the kernel parameter? Why not do this unconditionally? >>>> >>>> 1. Not all Macs have dual GPU. We don't want to unnecessarily "fool" >>>> the firmware in thinking macOS is being booted. >>>> 2. apple-gmux is a reverse engineered driver, although upstreamed, >>>> not very efficient in switching GPUs. So it's better to make unlocking >>>> the GPU optional. + not everyone wants the intel GPU, people are happy >>>> working with the dedicated AMD GPU (used by default if apple_set_os >>>> isn't enabled). >>> >>> So my opinion is that these aren't good arguments. We should be >>> identifying as Darwin by default in EFI, just as we've been doing >>> in ACPI since 7bc5a2bad0b8. If there are any adverse effects, >>> we should look into them, but users shouldn't be forced to set >>> an obscure kernel parameter only to enable certain features of >>> their hardware. It is for this reason that you'll usually get >>> Greg KH's trademark "this isn't the 90s anymore" comment when >>> adding new kernel parameters. We need to handle the hardware >>> correctly *automatically*. >>> >> I'm not in a favour of "forcing" dual GPU on users, especially because the features are quite unstable. On some distros like Ubuntu, since kernel 6.8, unlocking the GPU results in blank screen instead of igpu due to a regression (note that this patch has nothing to do with this regression, it's something the platform drivers people will look into). > > Is this just with apple-set-os or was > https://github.com/t2linux/linux-t2-patches/blob/main/2009-apple-gmux-allow-switching-to-igpu-at-probe.patch > and the kernel parameter it adds being used when that issue happened? Hi Orlando, thanks for replying My bad I should have checked this as well. Indeed removing the kernel parameter fixes the blank screen. > >> >> On the 2019 MacBook Pros the vgaswitchroo is not working and inputs from AMD are nil. Basically you get stuck to the Intel GPU and if you try to use the AMD GPU, but the GPUs remain on (currently no way has been found to switch off the AMD one) > > Do you mean that switching which gpu is connected to the display at > runtime isn't working? I *think* is is related to the not-upstream > patch I linked above? > >> >> So I guess we have 2 options: >> >> 1. Wait until apple-gmux becomes quite stable before merging this (fat chance) >> 2. Give me some better idea to handle this. >>
