Intel graphics on MBP 13,3

[mhkabir]

This might be interesting : http://lukeluo.blogspot.in/2014/04/mac-book-pro-113-linux-customization-2.html

Apple does not "expect" other OS running in rmbp. Its EFI firmware will power down some hardware if it realize you are not booting into OS X. At this time, the Intel Iris GPU won't show up.

Looking into how I can test this. I'm running refind, which directly hooks into the kernel stub loader, and thus doesn't use GRUB.

[mhkabir]

Moar resources :

1. http://unix.stackexchange.com/questions/193425/enabling-intel-iris-pro-syslinux-tails-system-macbook-pro-15-retina-late-2013
2. https://marc.info/?l=grub-deavel&m=141586614924917&w=2
3. https://github.com/0xbb/gpu-switch
4. http://lukeluo.blogspot.in/2014/04/mac-book-pro-113-linux-customization-6.html (The whole series of blogs seems very interesting. Much of it may not be applicable for our case, but it is still interesting.)

[mhkabir]

Trying to boot from refind with spoof_osx_version 10.12 causes boot to hang up at the place where it tries to load Xorg. So we are potentially on the right track.

@roadrunner2 you might want to have a look at this too, since you have a 13,3. Let me know if you have any ideas or are able to debug why it hangs.

[mhkabir]

Intel graphics is now powered on. I can get to a root shell by booting in no-graphics mode :

$ lspci | grep "VGA"
00:02.0 VGA compatible controller : Intel Corporation HD Graphics 530 (rev 06)
01:00.0 VGA compatible controller : Advanced Micro Devices, Inc. (AMD/ATI) Baffin [Radeon RX 460] (rev c7)

@roadrunner2 @Dunedan it still can't bring up Xorg, do you have any tips from how you forced the usage of intel as described here : https://gist.github.com/roadrunner2/1289542a748d9a104e7baec6a92f9cd7#gistcomment-1979884 ? I already tried booting with i915.modeset=0 but it doesn't help.

[mhkabir]

Already added this :

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   BusID       "PCI:0:2:0"
   Option      "TearFree"    "true"
   Option      "AccelMethod"  "glamor"
EndSection

I also blacklisted amdgpu.

Current status : Boots to root shell, but on starting Xorg/lightdm, everything freezes, with a single _ at the top of the screen. No longer responds to any keyboard input, and needs a force-shutdown.

Xorg logs don't indicate anything wrong.

Might be worthwhile trying this : https://github.com/0xbb/gpu-switch/blob/master/gpu-switch

[mhkabir]

@Dunedan @roadrunner2 Aaaand I have it working!

Instructions :

1. Make sure the EFI powers on the iGPU :

By default the Intel GPU gets switched off by the MacBook Pro EFI if you boot anything but OS X. So to use the Intel GPU, you need to trick the EFI by using the "apple_set_os" hack either with:

rEFInd version 0.10.0 or above (recommended): http://www.rodsbooks.com/refind

Recent versions of rEFInd have the "apple_set_os" hack built-in. You can enable it by setting the spoof_osx_version option in your refind.conf.

or

apple_set_os.efi: https://github.com/0xbb/apple_set_os.efi
or

a patched GRUB:
https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00442.html
https://wiki.archlinux.org/index.php/MacBookPro11,x#Getting_the_integrated_intel_card_to_work_on_11.2C3
or

a patched Kernel: https://www.marc.info/?l=grub-deavel&m=141586614924917&w=2
Otherwise you will end up with a powered-down integrated graphics card and a black screen.

I used refind, and set spoof_osx_version 10.12 in refind.conf. Works perfect.

2. Create a Xorg config for the Intel GPU :

$ cat /etc/X11/xorg.conf.d/20-intel.conf 
Section "Device"
	Identifier "Intel Graphics"
	Driver "intel"
	BusID "PCI:0:2:0"
	Option "TearFree" "true"
	Option "AccelMethod" "glamor"
EndSection

3. Clone gpu-switch and run it (from Linux) :

git clone https://github.com/0xbb/gpu-switch
cd gpu-switch
./gpu-switch -i # needs root. switches system to iGPU. needs reboot.

4. Reboot system

sudo reboot

You should have a working Intel card now with proper HiDPI detection! You can also blacklist the AMD driver in /etc/modprobe.d/blacklist.conf by adding blacklist amdgpu to the end of the file.

[mhkabir]

I can't boot into macOS (boot hangs) after running gpu-switch -i, but it works again after running gpu_switch -d.

Opened a refind discussion here https://sourceforge.net/p/refind/discussion/general/thread/84a55c48/ on whether we can do it from the bootloader automatically.

[mhkabir]

The core issue here is that card switching isn't handled correctly by the kernel yet. We need proper vgaswitcheroo support for new Retina models to avoid the gpu-switch stuff and be able to dynamically switch between GPUs.

https://www.phoronix.com/scan.php?page=news_item&px=Apple-GMUX-VGA-Switcher-4.6

[Dunedan]

Congrats for getting it to work. As I've a MacBookPro 13,2 without a separate AMD GPU I won't be able to benefit from your findings. Anyway, as this aims to be a complete guide I've of course already included a link to your instructions into the README: https://github.com/Dunedan/mbp-2016-linux/#intel

I can't boot into macOS (boot hangs) after running gpu-switch -i, but it works again after running gpu_switch -d.

As already mentioned on the refind-mailing list: All the gpu-switch utility does is to set a NVRAM variable, like I did for disabling the auto-boot feature (https://github.com/Dunedan/mbp-2016-linux/#disable-auto-boot). So you wouldn't necessary need it as a separate tool. That said: Can't you simply for now run it on shutdown with gpu-switch -i? That's still just a hacky workaround, but maybe better than nothing in the short term.

What I'd really like to see is the mentioned kernel- and/or grub-patch being applied upstream, as that would it make way more easier for the average user to use it.
@mhkabir Do you have in interest in pushing for that?

[Dunedan]

I had another idea in the meanwhile:
The change gpuswitch does is a "non volatile" one, so it's permanent across reboots. What you could do instead is to make it a volatile one, so a reboot would cause it to be erased again.

You should be able to easily achieve that by changing the \x07 to a \x06 in the following line: https://github.com/0xbb/gpu-switch/blob/master/gpu-switch#L46

For reference from the UEFI standard chapter 7.2:

//*******************************************************
#define EFI_VARIABLE_NON_VOLATILE 0x00000001
#define EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
#define EFI_VARIABLE_RUNTIME_ACCESS 0x00000004
#define EFI_VARIABLE_HARDWARE_ERROR_RECORD 0x00000008

and:

If the EFI_VARIABLE_NON_VOLATILE attribute is not set, the firmware stores the variable in
normal memory and it is not maintained across a power cycle.

[roadrunner2]

@mhkabir Excellent work! I played with this a bit, using the apple_set_os.efi which works quite nicely. Turning off the dGPU saves quite a bit of power (dGPU only: 17.2W, dGPU+iGPU and using iGPU: 16.2W, iGPU only: 11.1W).

However, I did run into several issues. First, when both drivers are loaded, Wayland won't start, i.e. we fall back to plain old X; but this appears to be a Wayland/Mutter issue. I was able to fix this by adding MUTTER_ALOW_HYBRID_GPUS=1 to /etc/environment. Second, if I power down the dGPU under X I often get long hangs as X apparently still tries to access the dGPU (despite the iGPU being the main one) - probably need to figure out a way to tell X to ignore the dGPU altogether. I also tried blacklisting the amdgpu module, but in this setup vga_switcheroo doesn't create the sysfs entries and hence the dGPU can't (easily) be turned off.

One big issue still remaining for me is that the console is garbled: booting with no quiet option I first see readable (though very small) output, but then it switches modes apparently after which the console output is completely garbled.

@Dunedan You can't change the flags - doing so just results in an EINVAL.

[mhkabir]

I wasn't able to get power consumption down that low :( What are you using to measure power draw?

I also have this interrupt, gpe07, which keeps firing continuously. That was definitely not helping power consumption, so I disabled it till a proper fix can be found. Any ideas on what's gpe07?

Regarding garbled text, it is fixed for me on kernel 4.11, but that kernel also seems to break the keyboard driver startup. I need to enter my encryption keys before the OS can be loaded, and post kernel 4.11, the keyboard does not come up before the encryption prompt from lvm. If I use an e.g USB keyboard, I can get in, and the SPI driver comes up afterwards (might also have something to do with my rc.local configuration because it reloads applespi a couple of time to try and improve chances of touchpad in it. )

[roadrunner2]

I measured the power consumption in several ways, but all of course with the power unplugged: cat /sys/class/power_supply/BAT0/current_now (together with /voltage_now), via powertop, and via the Gnome "Power Statistics" utility. I did this on a completely idle laptop with display at 50% brightness.

Regarding GPE 07, that appears to be from the embedded controller (see the dsdt.dsl) - I haven't noticed anything about that, but then again I wasn't looking - where do you see the fact that it's being fired a lot?

It's good to hear 4.11 will fix the garbled text - look forward to trying it. As for the loading of the applespi driver, I also need to enter the encryption key, and I originally had to figure out the list of kernel modules that are required so they could be added to the initrd (see the keyboard.conf on my gist). It may be that either an additional driver is needed on 4.11, or even that one was renamed - try looking at list of loaded modules for anything with spi or lpss in the name.

[Dunedan]

Regarding garbled text, it is fixed for me on kernel 4.11, but that kernel also seems to break the keyboard driver startup.

For me keyboard initialization during initrd works the same way with 4.11 as it did with 4.10, although I don't try to reload during that phase to get the touchpad working.