t2linux / wiki

Repository for the t2linux.org wiki
https://wiki.t2linux.org
Creative Commons Attribution Share Alike 4.0 International
181 stars 65 forks source link

The `Hybrid Graphics` guide results in a black screen on MBP16,1 #543

Closed Kir-Antipov closed 4 months ago

Kir-Antipov commented 6 months ago

Hi! First of all, thanks a lot for this project; it's been amazingly helpful to get a working keyboard, Wi-Fi, and other somewhat important stuff out of the box :D

However, I can't seem to get hybrid graphics working as described in the corresponding guide, which is especially strange considering it explicitly states that it should work on the MBP16,1. Whenever I set the apple_set_os kernel parameter via my GRUB config and run echo "options apple-gmux force_igd=y" | sudo tee /etc/modprobe.d/apple-gmux.conf, I just get a black screen on the subsequent reboot. (I can see the logs running for a second or so, then I assume the switch to iGPU happens, and the screen goes dark.) The only way to get out of this is to forcefully shut down the machine and then reboot it, omitting the apple_set_os parameter. Interestingly enough, journalctl -b -1 suggests there were no graphics-related errors, and the system successfully reached the login screen before I pressed the power button. I understand that this whole issue originally stems from Apple firmware shutting down the iGPU if you try to boot something other than macOS (wow, thanks Apple, very helpful!). However, to be quite frankly honest with you, I have never encountered problems related to powered-down graphics cards, so I'm not sure if this is what's happening in this exact case, as I would expect at least some graphics errors to show up if the system tries to use a disabled GPU.

If I remove either apple_set_os or /etc/modprobe.d/apple-gmux.conf, the device boots fine. In the first case, the iGPU is not recognized at all (i.e., it's not listed via lspci), and in the latter, it is recognized, but the dGPU is used by default. So, at least this part seems to work as expected.

Also, I tried to effectively replace apple-gmux.conf with the modprobe.blacklist=amdgpu kernel parameter (I don't really need hybrid graphics in the end of this journey, I just would love to bring the power consumption of the MBP down as much as possible), hoping it would result in a switch to the iGPU because the dGPU is simply not available. This does happen (at least according to glxinfo), but this approach produces some weird graphical artifacts (e.g., the cursor leaves a Windows 97-ish trail behind itself and other fun stuff), and the power consumption is still really high, signifying that the dGPU is not properly shut down, which is honestly to be expected with such a barbaric approach.

Additionally, I had a theory that the iGPU is working just fine, but the brightness is simply defaulted to 0. However, neither trying to bring it up via the touchbar, nor automatically setting /sys/class/backlight/gmux_backlight/brightness to a reasonable value like 32000 on startup helped, so, sadly, I guess this is not the case.

So, at this moment, I'm a little bit lost and would greatly appreciate a bit of assistance if somebody knows what is happening here and why :)


A bit more information on the steps that led me to this predicament:

  1. Follow the Pre-Install guide to the letter and opt-in for t2linux/fedora-iso.
  2. Copy the Wi-Fi firmware from macOS.
  3. Update the system (the kernel gets bumped to 6.8.10-300.t2.fc40.x86_64 atm).
  4. Follow the Hybrid Graphics guide to the letter.
  5. Get a black screen.
  6. Try intel_iommu=on iommu=pt pcie_ports=compat.
  7. Get a black screen.
  8. Try echo apple-bce | sudo tee /etc/modules-load.d/t2.conf.
  9. Get a black screen.
  10. Try a bunch of homebrewed approaches described above to fix the issue.
  11. Get a black screen.
  12. Re-install the system to start fresh.
  13. Once again, follow the Pre-Install guide.
  14. Copy the Wi-Fi firmware from macOS.
  15. Do not update the system; stay with kernel 6.7.7-200.t2.fc40.x86_64.
  16. Follow the Hybrid Graphics guide.
  17. Get a black screen.
AdityaGarg8 commented 5 months ago

Enter Mac OS Recovery on the next boot. You do that by pressing CMD + R while booting. From there look for the Terminal in the Toolbar. Inside the Terminal, enter following command:

nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

But be extremely sure that you typed it correctly, this can break things if you don't. Then exit the Mac OS Recovery and reboot into Linux.

If you, boot into Mac OS after that, you have to enter the command again from Mac OS recovery so that Linux can use the Intel Graphics Card correctly. Mac OS breaks it

AdityaGarg8 commented 5 months ago

You can also use https://github.com/0xbb/gpu-switch in Linux which does the same work as the nvram command

Kir-Antipov commented 5 months ago

Thanks a lot for your guidance, it's dearly appreciated! I was a little hesitant to use gpu-switch since it's mentioned on the wiki only as a solution for Windows, and the project hasn't received any updates in like 7 years. However, it turns out it still works like a charm! With it and a simple systemd service, I've finally been able to completely switch to the iGPU and power down the dGPU. As a result, the machine now consumes around 6 watts while idle, which is, ahem, much better than the whopping 60 watts it was using previously when both GPUs were all over the place.

So, did I miss something during the installation process? Why didn't apple-gmux work for me? Also, is it possible to make this change somewhat permanent? As you've mentioned, macOS does indeed screw up this whole endeavor every time I boot into it. At the moment, I need to first boot into Linux, run gpu-switch -i, reboot, and only then can I properly use my system. This is already quite inconvenient on its own, however, I'm also facing painfully long boot and shutdown times, so the whole reboot process may take up to 5 minutes!

I tried to set the NVRAM variable from the userspace, hoping that it could be trivially automated via a logout hook:

sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

However, it did nothing. Sadly, it only works from the recovery menu.

I noticed that gpu-switch fiddles with the immutable attribute on /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9:

chattr -i "${sysfs_efi_vars}/${efi_gpu}" 2> /dev/null.

So, I'm wondering what would happen if we set it after that, i.e.,

chattr +i "${sysfs_efi_vars}/${efi_gpu}"

Will it break macOS? Will it even respect that attribute?


P.S. - For those who also want to automatically power down their discrete GPU, here's how I did it:

1) First, create a script for that at /usr/local/sbin/disable-dgpu:

   #!/bin/sh
   echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
   echo IGD > /sys/kernel/debug/vgaswitcheroo/switch

2) sudo chmod 754 /usr/local/sbin/disable-dgpu 3) After that, wrap it into a systemd service at /etc/systemd/system/disable-dgpu.service:

   [Unit]
   Description=Disable dGPU
   After=multi-user.target
   Wants=multi-user.target

   [Service]
   Type=oneshot
   RemainAfterExit=true
   ExecStart=/usr/local/sbin/disable-dgpu

   [Install]
   WantedBy=multi-user.target

4) Finally, enable and start the service via systemctl enable --now disable-dgpu.service

AdityaGarg8 commented 5 months ago

Thanks a lot for your guidance, it's dearly appreciated! I was a little hesitant to use gpu-switch since it's mentioned on the wiki only as a solution for Windows, and the project hasn't received any updates in like 7 years. However, it turns out it still works like a charm! With it and a simple systemd service, I've finally been able to completely switch to the iGPU and power down the dGPU. As a result, the machine now consumes around 6 watts while idle, which is, ahem, much better than the whopping 60 watts it was using previously when both GPUs were all over the place.

So, did I miss something during the installation process? Why didn't apple-gmux work for me? Also, is it possible to make this change somewhat permanent? As you've mentioned, macOS does indeed screw up this whole endeavor every time I boot into it. At the moment, I need to first boot into Linux, run gpu-switch -i, reboot, and only then can I properly use my system. This is already quite inconvenient on its own, however, I'm also facing painfully long boot and shutdown times, so the whole reboot process may take up to 5 minutes!

Your concert regarding apple-gmux is genuine. Actually a kernel regression has broken apple-gmux, and the author of the patches to the driver, @Redecorating (pinging him for a reminder) is a little busy.

I tried to set the NVRAM variable from the userspace, hoping that it could be trivially automated via a logout hook:

sudo nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00

However, it did nothing. Sadly, it only works from the recovery menu.

I noticed that gpu-switch fiddles with the immutable attribute on /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9:

chattr -i "${sysfs_efi_vars}/${efi_gpu}" 2> /dev/null.

So, I'm wondering what would happen if we set it after that, i.e.,

chattr +i "${sysfs_efi_vars}/${efi_gpu}"

Will it break macOS? Will it even respect that attribute?

I wouldn't fiddle with NVRAM variables too much tbh.

P.S. - For those who also want to automatically power down their discrete GPU, here's how I did it:

  1. First, create a script for that at /usr/local/sbin/disable-dgpu:
    #!/bin/sh
    echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
    echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
  2. sudo chmod 754 /usr/local/sbin/disable-dgpu
  3. After that, wrap it into a systemd service at /etc/systemd/system/disable-dgpu.service:

    [Unit]
    Description=Disable dGPU
    After=multi-user.target
    Wants=multi-user.target
    
    [Service]
    Type=oneshot
    RemainAfterExit=true
    ExecStart=/usr/local/sbin/disable-dgpu
    
    [Install]
    WantedBy=multi-user.target
  4. Finally, enable and start the service via systemctl enable --now disable-dgpu.service

if your distro maintainer offers an LTS kernel variant, you can try that, maybe it shall work without fiddling with NVRAM.

Kir-Antipov commented 5 months ago

Oh, so it's just a regression, and in the future, it may/should work again out of the box? Got it! I'll try out an older version of the kernel in the meantime then :)

Once again, thanks a lot for your help!

AdityaGarg8 commented 5 months ago

Oh, so it's just a regression, and in the future, it may/should work again out of the box? Got it! I'll try out an older version of the kernel in the meantime then :)

Iirc, it was introduced in kernel 6.8. So you can try 6.6 LTS. Although, it's possible the regression got backported, and I haven't tested iGPU myself for a long time tbh. I'll probably give it a try with LTS soon. Once again, thanks a lot for your help!

AdityaGarg8 commented 5 months ago

Oh, so it's just a regression, and in the future, it may/should work again out of the box? Got it! I'll try out an older version of the kernel in the meantime then :)

Once again, thanks a lot for your help!

Tested apple-gmux on kernel 6.6.32, and it still works there! The nvram variable needn't be messed up with over there :)

image

Kir-Antipov commented 5 months ago

Thanks! Gonna try that :)

Redecorating commented 5 months ago

Hmm I'm not able to reproduce this on arch with 6.9.2 6.8.2 or 6.7.6. I'm also on MBP16,1 and I don't have the nvram set to make the igpu the boot gpu. Maybe this is specific to fedora?

AdityaGarg8 commented 5 months ago

Hmm I'm not able to reproduce this on arch with 6.9.2 6.8.2 or 6.7.6. I'm also on MBP16,1 and I don't have the nvram set to make the igpu the boot gpu. Maybe this is specific to fedora?

Issue is even on Ubuntu

Redecorating commented 5 months ago

I just get a black screen on the subsequent reboot. (I can see the logs running for a second or so, then I assume the switch to iGPU happens, and the screen goes dark.) The only way to get out of this is to forcefully shut down the machine and then reboot it, omitting the apple_set_os parameter. Interestingly enough, journalctl -b -1 suggests there were no graphics-related errors, and the system successfully reached the login screen before I pressed the power button.

This sounds like gmux thinks it switched the display over to igpu properly but it actually didn't get switched properly so its blank, while the operating system thinks its connected to a functional screen. If you have a second display you might be able to plug your computer into that and see if its working. If someone on an impacted distro running a kernel that has the issue can send /proc/config.gz i can see if using a similar kernel config lets me reproduce the issue.

AdityaGarg8 commented 5 months ago

I just get a black screen on the subsequent reboot. (I can see the logs running for a second or so, then I assume the switch to iGPU happens, and the screen goes dark.) The only way to get out of this is to forcefully shut down the machine and then reboot it, omitting the apple_set_os parameter. Interestingly enough, journalctl -b -1 suggests there were no graphics-related errors, and the system successfully reached the login screen before I pressed the power button.

This sounds like gmux thinks it switched the display over to igpu properly but it actually didn't get switched properly so its blank, while the operating system thinks its connected to a functional screen. If you have a second display you might be able to plug your computer into that and see if its working. If someone on an impacted distro running a kernel that has the issue can send /proc/config.gz i can see if using a similar kernel config lets me reproduce the issue.

https://github.com/t2linux/T2-Debian-and-Ubuntu-Kernel/releases/download/v6.9.4-1/kernel_config_6.9.4-noble

AdityaGarg8 commented 4 months ago

The latest kernel has the bug fixed. Please test now.

linuxdigital commented 4 months ago

Hi,

Work’s flawlessly on fedora 40

Thanks!

Cumprimentos,

António Paulo Santos

Aditya Garg @.***> escreveu em sex., 5/07/2024 às 18:31 :

The latest kernel has the bug fixed. Please test now.

— Reply to this email directly, view it on GitHub https://github.com/t2linux/wiki/issues/543#issuecomment-2211192779, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEHLSJKSS6NKEHNSDTEVWDZK3KAJAVCNFSM6AAAAABIN75AIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJRGE4TENZXHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>