Getting switchable graphics to work on a macbookpro10,1 about gmux-scripts HOT 64 OPEN

@0xbb

Ran nvram-dump on mid-2014 rmbp (GT 750M / Iris Pro) with gfxCardStatus 2.2.1.

Steps: Fresh boot into 10.10, switch to "Discrete Only", "Sleep", ./nvram-dump 2>&1 | cut -d' ' -f4-:

FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-active
<00000000>
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-power-prefs
<00000000>
gpu-policy
<01>
7C436110-AB2A-4BBB-A880-FE41995C9F8:gpu-policy
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:DisplayBackgroundColor
backlight-level
<0c01>
7C436110-AB2A-4BBB-A880-FE41995C9F8:backlight-level
7C436110-AB2A-4BBB-A880-FE41995C9F8:GfxMode
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:backlight-regs
<0c000c01 0c010c01 ff030000 0c010000>

Then "Integrated Only", "Sleep", dump:

FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-active
<01000000>
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:gpu-power-prefs
<01000000>
gpu-policy
<01>
7C436110-AB2A-4BBB-A880-FE41995C9F8:gpu-policy
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:DisplayBackgroundColor
backlight-level
<0c01>
7C436110-AB2A-4BBB-A880-FE41995C9F8:backlight-level
7C436110-AB2A-4BBB-A880-FE41995C9F8:GfxMode
FA4CE28D-B62F-4C99-9CC3-6815686E30F9:backlight-regs
<0c000c01 0c010c01 ff030000 0c010000>

Results were repeatable. Looks like we can see some bits flipping :)

from gmux-scripts.

Switching works reliably for me, if you boot linux with the Intel card enabled and then do the applegmux switch and the driver reloading, before performing the vgaswitcheroo command.

E.g.:
echo DIS > /sys/kernel/debug/applegmux/switch
modprobe -r nouveau
modprobe nouveau
echo DIS > /sys/kernel/debug/vgaswitcheroo/switch

My setup is pretty advanced right now. I start up a second X server with some kind of multiseat setup, whenever I am using my dedicated card, and switch between both X servers using the applegmux switch. I do not think that my config files would help you.
It's quite cool, what you can do with this switch. I even got vga passthrough with qemu and kvm to work, but the windows nvidia driver fails.

from gmux-scripts.

Hi Victor,

Great work!
I think there has been some progress lately, somebody tried to get it to work in January (see https://lkml.org/lkml/2014/1/7/91 and a few more posts), and just a few weeks ago there was this: http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/5547, which tries to fix the exact issues that are keeping your screen black.

The things in this repo (and most of my code that's not already in the kernel) is pretty outdated, so I'd say the best way forward would be to try out the newest patches from Matthew. Fetch the kernel source from git, check if those patches are already included, if not apply them and see if it works.
It seems that you already have a good grasp of how to compile and run it, so your testing effort will certainly be appreciated. And if that is still broken you can fix it!

When I started out with this, I got a lot of help from people on IRC, so try your luck in #dri-devel on irc.freenode.net, if you ask nicely I'm sure you'll get quick help there if you get stuck. You might also find Matthew (mjg59) on there.

And kernel development can seem pretty complicated, but you can do it if you invest some time, and it's a lot of fun when you finally get it working!

Cheers,
Andreas

(And I'm German, I just think it's a good idea to keep this in english and public so the next person who might be interested can find this. But if you have some questions about how to get started, feel free to write me at [email protected])

from gmux-scripts.

Thank you so much for those links!

After you did point me to the correct direction, I found this: http://mjg59.dreamwidth.org/29817.html .
And then (after some looking around in his public web space, linked through the test patches) I found the holy grail for my laptop as it seems: http://www.codon.org.uk/~mjg59/tmp/retina_patches/

Going to try those out tomorrow and will report back. I am still interesting in starting "hacking" the kernel to my needs, but it's so nice not to need to do so for a (hopefully) running productive system.

from gmux-scripts.

I'm pretty sure those are somewhat outdated as well, try this: https://patchwork.kernel.org/patch/4279461/, the other patches are also on patchwork: https://patchwork.kernel.org/project/dri-devel/list/?submitter=56451

There's a small link to download the patches on there. Let me know if they work, I'm currently using a MBP 11,3 and switching is broken on mine as well, so if you get it running I might give it another try!

from gmux-scripts.

"the other patches are also on patchwork"
Not really the case, the other patches in the patchset are related to backlight controls and not even to the backlight of the macbookpros as it seems.

The apple-gmux and vgaswitcheroo patches have indeed a newer timestamp, but interdiff shows, that they do not differ at all.

Also this patchset is lacking of the necessary i915 and nouveau patches required for using the new apple-gmux and vgaswitcheroo structure.

So using the retina-patches is still my best attempt. Just for the record, nearly all of those patches can still be patched on kernel version 3.15.6. About 3 just fail and I will try to fix them today. If I get anything to work, I will post the progress and upload the updated patches to my github account.

from gmux-scripts.

Okay so the patches do at least something, but they are not (at least not with recent kernel versions) fully working.

Switching to the Intel Chip still results in a black screen. This does now also apply, if the mux is switched to the Intel Chip at boot time (using Grub or gfxcardstatus 2.2.1). So the eDP detection is not working, LVDS probably is, but thats not what my macbook is using. The i915 patches definitely need to be adjusted.

Switching back to the nVidia Card works nicely however just one time. The first time I enable it again after powering off I can get my screen back (with framebuffer console this time!!) but on the next cycle it breaks. Nouveau prints a bunch of stuff into the log, it looks like the somewhat in the state got corrupted by the power management of the apple_gmux introduced by the patches. So here is also room for improvement. A quick fix would probably be just to remove the new power management part, but some serious debugging would probably work out better.

While the later one is probably easier to fix (or at least to work around), the first bug requires implementing proper reprobing of the connectors, at least thats my theory.

The patched intel_reprobe_connectors function seems to only reprobe LVDS connections. The preferred way of obtaining the edid on eDP connections is via vga_switcheroo. The patches implemented functionality of sharing panel data via vga_switcheroo. However at least on my laptop the nouveau driver loads after the i915 driver, so there is no data to collect, when the i915 is asking for it and detection still fails.

I am on holidays for at least a week now, so there will not be much progress in that time. I hope Matthew just updates his patches in the meantime ^^

from gmux-scripts.

I have a 10,1, same as @Drakulix.

A few questions: is calling the "apple_set_os" EFI protocol still required for using the intel with the gmux? Apple has apparently interlocked the GPU on in the event of booting a non-Apple OS, presumably to avoid the (substantial) extra engineering work of implementing full gmux/hybrid graphics support in Windows.

@ah- wrote a patch for Grub that calls apple_set_os, and other users (on MBP 11,x's: https://wiki.archlinux.org/index.php/MacBookPro11,x) have gained access to the Intel GPU by using GfxCardStatus to force the system to "Integrated" mode and then doing a warm reboot through @ah-'s patched Grub. xf86-video-intel works by default, but the nvidia GPU remains powered on. I seem to have confirmed that this also true on my 10,1. @Drakulix, did you use the Grub patch?

Incidentally, I've hacked support for apple_set_os into Refind, the bootloader I use on my 10,1, rather than setting up some contorted chainloading arrangement to boot through Grub instead. https://github.com/orospakr/refind

@ah-, what has your strategy been for researching these undocumented functions of Apple's kit (both firmware and hardware)? Namely, how did you discover the GUID of the apple_set_os protocol, to say nothing of the gmux itself?

from gmux-scripts.

What a coincidence someone comments here, just the day I got switching to work!

@orospakr
At first about your questions. The apple_set_os protocol should only be required when booting in BIOS Mode (but I never tested that). It is not necessary at all for EFI booting. I use a completely unpatched Grub. Switching to the Intel GPU at boot seems to be more reliably via GfxCardStatus. Setting the correct commands in my grub.cfg (all that outb 0x7** 0x* stuff) should work as well, but sometimes fails for no reason on my mac.

So and now the big news. After trying hours and days to patch nouveau and intel, I realized, that all I really needed was a way to switch the mux without both drivers being loaded, so I needed an interface for switching, that did not require vga_switcheroo.

And this is what I have come up with: https://gist.github.com/Drakulix/1064a8e18f6feab6a604

This adds a apple_gmux folder with a "switch" file just like switcheroo's to /sys/kernel/debug.

Now I can boot with i915 blacklisted (modprobe.blacklist=i915 as kernel parameter) and then after booting (with nouveau loaded), I can just use this command to switch to the integrated card and power off the nVidia:

echo IGD > /sys/kernel/debug/apple_gmux/switch; modprobe i915; echo IGD > /sys/kernel/debug/vgaswitcheroo/switch"

after that switching works reliably with these two commands:

switching to nVidia:

"echo ON > /sys/kernel/debug/vgaswitcheroo/switch; rmmod nouveau; echo DIS > /sys/kernel/debug/apple_gmux/switch; modprobe nouveau; echo DIS > /sys/kernel/debug/vgaswitcheroo"

switching to Intel:

"echo IGD > /sys/kernel/debug/apple_gmux/switch; echo IGD > /sys/kernel/debug/vgaswitcheroo/switch"

Unloading the nouveau driver is not required all the time, but it appears that it sometimes reprobes before switching to the Intel Card. That fails and the driver reports "link training failed". The only way to force reprobing is through reloading the nouveau driver, which works ALL the time. The Intel driver does not suffer from this bug.

The debugfs should also be usable to get the nvidia blob to load somehow, but I did not test that yet.
Also it should work on every MacBook that suffers from that problem, because all is done manually.

Right now the patch is considered WIP, because I still need to add a mutex (in this version a race condition may happen, when you use switcheroo and my sysfs at the same time, so be careful), but I will fix that the next days and then try to get this into mainline.

from gmux-scripts.

Congratulations! Hats off to you, sir!

Are you going to continue trying to patch the drivers? Any theories as to why switching the mux with the drivers loaded fails?

Btw, what patches (or kernel branch) are you using right now outside of your debugfs gmux patch?

from gmux-scripts.

I will probably not try to patch the drivers themselves. I have spend far too much time on that already and I just do not know the driver code good enough to provide some stable patches. Basically the drivers do probe for displays at the wrong time and you cannot force a re-probe yourself on any driver.

What would need to be necessary to rely on switcheroo on it's own, would be fixing the order of turning displays and graphics on, switching the mux and probing for displays.
The order that is currently used, must be pretty fucked up, because even the well coded i915 driver fails when just using switcheroo, which should switch the mux early enough, but as we can clearly observe, it does not!

Driver unloading is just necessary for nouveau, which seems to be totally broken in that respect. (Why would you do probing on shutting down the card, instead when you powered it on again??)

I have build the patch successfully against some 3.15 and the latest stable 3.16 kernels (on arch-linux). But 3.17-rc* should also work, because non of them modify the apple_gmux.c file. As long as that does not happen, this patch should work on any new version and I will try my best to maintain it. (I will add a real repository, once I did clean it up.)
If you have an older kernel version and the patch does not apply correctly, just tell me. Should be quite easy to fix, but I will focus on mainline kernels.

The current code is pretty simple, and I am happy enough with the solution, so this is probably the best, we macbook users will get, for a long time. And it is better then nothing for sure.

from gmux-scripts.

Gist updated with mutex, but untested atm.

from gmux-scripts.

Here is another coder working on gmux:

http://www.kevxu.net/2014/05/force-intel-graphics-on-2012-retina.html
https://gist.github.com/kevinxucs/da371fec14d2df2bb9ad

Maybe his findings can help you?

from gmux-scripts.

Thanks for you comment, but those "findings" are well known and even made it into the Arch Linux Wiki: https://wiki.archlinux.org/index.php/MacBookPro10,x

I am just cleaning up my patch, I will offer something "final" this weekend, I suppose. And I do not intend to spend any more time on patching the graphic drivers.

from gmux-scripts.

Hi Drakulix,

Could you provide your dmesg after intel card power on?
I applied your patch, and it seems to work correct, because backlight is working.
However, screen is black anyway. I tested it with last gentoo-kernel-3.17.4.
Also it would be great if you can show your kernel config (maybe I missed something?).
Maybe you applied some other patches except of your?

Thank you for the great work!

from gmux-scripts.

I am using arch linux with the default kernel config. I am not sure, what the exact config is, but you should be able to find it in the internet. I am currently still running 3.17.1, but I do not see any difference in the patched file to 3.17.4. I did apply some other patches, but they are not related to graphics in any way.
Do you boot with your intel or nvidia card enabled at startup? Booting with the Intel card works rock solid for me, however thats not default. The best way to change it, is booting into OSX and use gfxCardStatus v2.2.1 (the version is important) to switch to the intel card. This setting persists across reboots and you need to boot into mac os twice to reset it.
If you still need some help, you can mail me via "drakulix @ portingteam.com".

from gmux-scripts.

Thanks!
The problem was that for correct work integrated card should be loaded first. Now all works like a charm. Woohoo =)

P:S: It looks like in new kernels 3.17.4+ switching works even withought this patch. However, after turn on nvidia card resolution is uncorrect. In this case your patch helps. I described this situation here:
https://bugzilla.kernel.org/show_bug.cgi?id=88861

from gmux-scripts.

Are you using the nouveau or nvidia drivers for your nvidia card? Because I can guarantee that the nVidia blob cannot handle the missing eeid. The nouveau driver seems to handle this better now, but of course without being able to read the eeid (which my patch fixes), it cannot detect any resolutions, so thats expected.

from gmux-scripts.

I'am using nouveau+intel. I thought that it is even not possible to use nVidia blob with efi kernel.
Will try soon. Which version do you suggest?

from gmux-scripts.

Latest

from gmux-scripts.

Hi everyone!
I would like to help getting switchable GPUs working for the MacbookPro 11,3.
Just let me know if you have anything to test or if I should help out with a bugreport.
I can provide a MacbookPro 11,3 with:

• Debian and Mac OS X 10.9 (in case gfxcardstatus 2.2.1 is need)
• patched grub with "apple_set_os"
• custom Kernel and I can apply patches to it

Thank you for the great work!
Bruno

from gmux-scripts.

Hi Bruno,

that sounds like you have everything ready for some testing! I'm not entirely sure what the current status of GPU switching is, but from time to time interesting things end up in my inbox, so you could check out a few of them and document how well they work:

1. Michael Marineau posted an implementation of apple_set_os directly in the linux kernel, which would make booting much easier: https://www.marc.info/?l=grub-devel&m=141586614924917&w=2 https://www.marc.info/?l=grub-devel&m=141586614924917&q=p3
   You could check if that patch still works with the newest kernel, post an updated version if it requires minor changes and popularize that method if it works well by adding it the wiki of your favourite distribution.
2. Test how well switching works right now with what Paul posted here: https://bugzilla.kernel.org/show_bug.cgi?id=88861

from gmux-scripts.

Hi Andreas,
thanks for the quick response!
I will give the two points a try and report back here!

from gmux-scripts.

I gave Michael Marineau's implementation of apple_set_os (https://www.marc.info/?l=grub-deavel&m=141586614924917&w=2) directly in the linux kernel a try.
So the modified version of the kernel (3.18) on a Macbook Pro 11,3 gave me these results:

• Booting with EFI -> Grub-EFI -> Linux: only the Nvidia GPU is available,
• Booting with the EFI stub directly: Intel GPU + Nvidia GPU are available 👍

I used this manual https://wiki.debian.org/EFIStub for directly booting the Linux kernel from EFI.

So futher tests of switching between the GPUs has to be done.

from gmux-scripts.

That's great, I think it doesn't work with EFI -> Grub-EFI -> Linux because Grub-EFI already does the exit boot services EFI call, which then disables the Intel GPU, before the patched Linux kernel had a chance to do the set os thing. But direct EFI stub booting is really how we should boot on Macbooks, so that's no big problem.

If you want to help other people, it'd be really useful to write this down in some wiki where others can see it. There are a number of MBP 11,3 guides around, which all refer to the grub patching method, these should really get updated to at least mention this better option.

If you want to get into kernel development you could try and get this patch into mainline, possibly disabled by default with a commandline parameter to enable it. I think it's not particularly hard to write the code but requires bugging the right people to get it accepted.

from gmux-scripts.

@ah- I agree that we should boot via EFI and your explanation with the exit boot call makes sense.
I also agree with updating the wikis, I will do so in the near future.
Patching the kernel and booting directly via EFI stub sounds much better then adding more stuff to grub.
I am really interested in kernel development and that sounds like a really good starting point.

Could I directly contact you if I need further help/review there?

I forked @Drakulix's apple_gmux debugfs patch (https://gist.github.com/Drakulix/1064a8e18f6feab6a604) to make it work with 3.18: https://gist.github.com/0xbb/836f710e52686e1b1aee

from gmux-scripts.

What did you need to fix for 3.18?
My patch is still working for me, even with 3.18, maybe I have an outdated version on gist.

Also, that you need to use EFI stub boot is odd. I never heard, that the apple efi is disabling the intel gpu, if you do not boot via CSM. I am booting with an unpatched grub-efi bootloader quite fine.
I am curious, what is your disk layout? I am booting with a layout similar to this tutorial, you might wanna try that, if you want a boot loader: http://glandium.org/blog/?p=2830

from gmux-scripts.

@0xbb: Of course, feel free to write me at [email protected] if you want me to look over something or you get stuck at any point. http://kernelnewbies.org/ is also a great community to get started with all this and you'll always find helpful people there.

@Drakulix: Apple changed the EFI between the MBP 10,1 and 11,3 and now completely disable the Intel GPU on the exit boot services call without the patch to Linux or Grub. This is only required for MBP 11,3 and up. I guess this is related to them now supporting Windows booting directly via EFI instead of only via the CSM on older MBPs.

from gmux-scripts.

@Drakulix Frankly, I don'tk know patch refused to accet it and so I applied it by hand. Could you supply our latest version? I will remove the useless fork then.

Hm, that sounds really interesting! Maybe I and a lot of people are booting Linux in a different way and so have to deal with "apple_set_os" to get access to the Intel GPU. Are you also using a Macbook Pro 11,3?

That's my layout:

Device         Start       End   Sectors   Size Type
/dev/sda1         40    409639    409600   200M EFI System
/dev/sda2     409640 874580687 874171048 416.9G Apple Core storage
/dev/sda3  874580688 875850223   1269536 619.9M Apple boot
/dev/sda4  875851776 895381503  19529728   9.3G Linux filesystem
/dev/sda5  895381504 897959935   2578432   1.2G Linux swap
/dev/sda6  897959936 977104895  79144960  37.8G Linux filesystem

from gmux-scripts.

@0xbb
No I still have a Macbook Pro 10,1 (first gen retina), so I am not sure, if it is the EFI firmware, or the boot setup. I am just using the linked setup because it allows a more easy multiboot and it feels "right" to boot that way on a macbook. Is your grub installed into the MBR or does it show up in Apple's EFI Loader? Or are you using refind or similar to get into it? If it is installed into the MBR, EFI is loading the CSM module and disabling the Intel GPU for sure.
I will check the gist in the next days, I am on the wrong computer right now.

from gmux-scripts.

@ah- That makes sense, although I can also boot Windows in UEFI mode on my system. It is just unsupported and has some undesired effects. (Like windows using the intel gpu, if I switched to it via gfxCardStatus, which is not what I want, when I boot windows for some games ;) )

from gmux-scripts.

@Drakulix Ah ok, I thought you have a Macbook Pro 11,3 too.
I will also give your boot setup a try, but I think @ah- is right that the Intel GPU is completely disabled by EFI on this machine. My grub is installed in ESP and yes it shows up in the Apple's EFI loader.
If I boot the kernel using the EFI stub (omitting grub) EFI jumps directly in to the kernel. Using both boot methods I am clearly in the EFI mode (checked using dmesg and efibootmgr).

Could also give me your current commands for switching between the GPUs?
I am not sure witch one are the latest and none of the posted ones seem work right for me.

Btw, has anyone already found out how gfxCardStatus permanently switches the GPU? It would be nice to reproduce that behavior under Linux.

from gmux-scripts.

Yeah finding out how gfxCardStatus switches would really be interesting. I'm quite annoyed that I haven't been able to yet :).

It's not actually gfxCardStatus that does the permanent switching, gfxCardStatus just calls into Apples switching driver to do the switching. I think it uses a deprecated method, which is why it behaves a bit differently from what the other switching methods (e.g. the energy saving panel in system settings) do.

I suspect it sets a flag somewhere in nvram/the efi variables, but I haven't found out which one exactly. Maybe I just overlooked it, and looking at a diff of a dump before and after gfxCardStatus might help. Or it uses something completely different, no idea. I have some free time around Christmas, maybe I'll spend a few days reverse engineering this then.

from gmux-scripts.

Haha, good that I am not the only one who failed there ;) .
I have the same thoughts about the switchting process, but at I haven't found anything either.
OK, we will see.

from gmux-scripts.

Booting Linux with the Intel card enabled works and switchting to the Nvidia too.
Using this commands:

echo DIS > /sys/kernel/debug/applegmux/switch
modprobe -r nouveau
modprobe nouveau
echo DIS > /sys/kernel/debug/vgaswitcheroo/switch

But swichting back to the Intel one always results in a black screen.

from gmux-scripts.

How exactly do you switch back?
Just try the exact opposite:

echo IGD > /sys/kernel/debug/applegmux/switch
modprobe -r i915
modprobe i915
echo IGD > /sys/kernel/debug/vgaswitcheroo/switch

from gmux-scripts.

Yep, that's excatly what I have tried.
I only get a black screen so far.

from gmux-scripts.

I started reverse engineering Apple's swichting driver and documented the results so far here:

https://gist.github.com/0xbb/974999591da4b1b2635c

Feel free to join in and/or comment :)

from gmux-scripts.

@0xbb: Do you have an email address?

from gmux-scripts.

@ah- I mailed you

from gmux-scripts.

Hello,
Andreas and I are working on a Linux replacement for gfxCardStatus v.2.2.1 : https://github.com/0xbb/gpu-switch
I only have access to a MBP 11,3 and MBP 5,1.

So it would be super nice if you guys could help us by running this small test tool: https://github.com/ah-/nvram-dump to reverse engineer Apple's driver:

• start OS X
• gfxCardStatus -> dedicated only
• suspend the Macbook
• run ./nvram-dump
• gfxCardStatus -> integrated only
• suspend theMacbook
• run ./nvram-dump

Paste output here :)

from gmux-scripts.

I will add that neither gfxCardSwitch nor gpu-switch works to disable the discrete GPU in linux (kernel 3.17.6-300.fc21.x86_64). This is with an apple_set_os patched grub. I still see both GPUs enabled, and powertop reports a lap-scorching 26W battery discharge:

# lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Crystal Well Integrated Graphics Controller (rev 08)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M Mac Edition] (rev a1)

from gmux-scripts.

@sprin thank you very much for your report and testing gpu-switch!
Your results are the same as ours and it's seems that we are able to fake Apple's gmux driver behavior :) .

For your burning legs you could try to switch off the discrete GPU with:

echo OFF > /sys/kernel/debug/vgaswitcheroo/switch 

from gmux-scripts.

@przhu: After reading your post at https://github.com/ah-/switcher/issues/2 again, maybe just try setting gpu-power-prefs to 01000000. I think this does exactly what GfxCardStatus does, and causes my mbp 11,3 to boot with just the Intel card enabled and broken switching in OSX, which is just what you want. No idea if this actually works, but might be worth a shot. Maybe also try shutting down the DGPU with "mm 0750 -IO 0".

See http://forums.macrumors.com/showpost.php?p=20529412&postcount=1045 for some documentation on how to set it if you don't have a linux install handy.

from gmux-scripts.

@ah- ,

The system knows its previous failure, it will continue to try previous wrong settings :}
(emptying nvram vars does not work, you have to provide some `correct' ones, ) most likely
an OS problem since I can restore normal boot by using time machine ...

nvram gpu-policy=%01 and then boot verbosely -> ok and then I can force integrated only using gfxstatus 2.2.x. In this case, the switcher reports:

    Policy: ON
    Auto_PowerDown_GPU: ON
    Dynamic_Switching: OFF
    GPU_Powerpolling: ON
    Defer_Policy: ON
    Synchronous_Launch: ON
    Unknown Feature: OFF
    Unknown Feature: OFF
    Backlight_Control: ON
    Recovery_Timeouts: OFF
    Power_Switch_Debounce: OFF
    Unknown Feature: OFF
    Unknown Feature: OFF
    Unknown Feature: OFF
    Unknown Feature: OFF
    Unknown Feature: ON
    Logging: OFF
    Display_Capture_Switch: OFF
    No_GL_HDA_busy_idle_registration: ON

The only changed feature is 'Dynamic Switching' , Disable Policy does not work.
Some bad apps may still access my broken(even poweroff'ed) DGPU (when they are crashed?). One notable bad guy is Preview.

Apple now stores SystemConfiguration in somewhere.. old plists mentioning GPUswitch does not make sense ...

I'm not sure what gpu-power-prefs does. Setting it to anything else than %01%00%00%00 ONCE makes the system fail to boot. Setting it to %01%00%00%00 does not disable dynamic switching (or the interface failed to reflect the correct status?)

setting gpu-policy to %03 will be changed to %01 by the system itself.
setting boot-args='agc=1' also sets gpu-policy to %01.
setting gpu-power-prefs also makes changes to gpu-policy (mmm maybe I'm lost ).

I will try later since the recovery from every single wrong setting may cost much time ...

from gmux-scripts.

Hi There,
I don't know if this is the correct place to ask for help :)
I have a macbookpro10,1 with frequently failing discreet GPU, I wanted to force MacOSX 10.10 to only use integrated only.
I tried "sudo nvram gpu-power-prefs=%01%00%00%00" and after rebooting gfxCardStatus was still set to Dynamic Switching.

Am I missing something ? please advice.

Thank you all for this great progress.

from gmux-scripts.

@jamyl Note that if you're using any recent version of gfxCardStatus, it sets the mode to Dynamic Switching on launch (and on quit). Try:

• removing gfxCardStatus from your Login Items
• running the nvram command again
• rebooting

And then run system_profiler SPDisplaysDataType after launching some apps that would normally turn the discrete GPU on, which will allow you to determine which GPU is active (i.e. whichever GPU has a Displays: section with Color LCD in it).

from gmux-scripts.

Actually, the steps should be:

• quit gfxCardStatus
• remove gfxCardStatus from your Login Items
• run the nvram command again
• reboot

from gmux-scripts.

Hi,
Thanks for your help.
I tried some heavy apps, but it only show Intel HD Graphics.
Right now it's only detecting Chipset Model: Intel HD Graphics 4000 in system_profiler SPDisplaysDataType.
I assume the discreet GPU is gone :(
I tried few reboots after running the command, and some gives me black screen.

Is there a way to disable completely the switching to failing discreet GPU ?

Thanks

from gmux-scripts.

@jamyl I'm not sure why you're sad about the result of running that command — it sounds like it did exactly what you wanted. If only the integrated chipset is detected, it won't bother trying to switch to the discrete GPU.

from gmux-scripts.

It's intermittent now, after some reboots it detect the discreet GPU and sometime it doesn't.
It seems it is still dying :)
When it detect both GPUs, soliciting heavy graphics apps gives me a black screen.

I am looking for a way to completely disable the failing discreet GPU.
Thanks a lot for your help.

from gmux-scripts.

my local Apple support says that if the discrete graphic card is broken, you have to replace the logic board as a whole. The cost: 3000 CNY ( 480 USD at current rate).
They haven't provided any method to disable the discrete graphics till now.

the brief procedure:

1. The local support runs hardware test.
2. if broken, determine the correct model and order a new one from Apple (never in stock)
3. bring back your machine or leave your machine at the local hardware support.
4. wait for the new hardware
5. replace

from gmux-scripts.

@przhu Same here, the cost for replacing the logic board was 570 Canadian Dollar.
I am not willing to replace this, i can live without the discreet GPU if it is still usable.
I don't think the solution will come from Apple or with AppledontCare.

That is why I am looking desperately for a permanent fix.

from gmux-scripts.

Hello everyone,

Will the same command sudo nvram gpu-power-prefs=%01%00%00%00 work on MacBookPro11,3 (15" Retina, Mid 2014)?

I'd like to try it but assuming it works I have a couple questions:

• What is the command to undo it / reset to dynamic switching again?
• Out of curiosity, does this command allow multiple monitors to work under integrated GPU?

Thanks a lot.

from gmux-scripts.

It should work, to undo just reboot twice and it'll be gone, and I think it won't make the monitors work as there might no longer be a line from the integrated GPU to external monitors.

from gmux-scripts.

Aha, so this command is not persistent? I mean: affects one reboot only?

(should be easy to workaround it of course with login items or something)

from gmux-scripts.

Yes, it affects one reboot. You run it, nothing happens immediately, then you reboot and it should stick to intel only, then you reboot again and it's back to normal.

from gmux-scripts.

well gpu-power-prefs does not work with mine :(
it's a late-2011 15'' with AMD card.

if I removed all AMD/ATI drivers, the system can boot and treat my screen as
an external display -- and using discrete graphics in some mode :( well, I haven't load
the framebuffer driver either.

so I'm now interested in selectively enabling drivers.

from gmux-scripts.

I have a 6750M (but now the system says it is 6770M ... the same, only clock rate difference), related drivers are:

1. AMD6000Controller.kext
2. AMDRadeonX3000.kext, AMDRadeonX3000GLDriver.bundle and AMDRadeonVADriver.bundle
3. AMDFramebuffer.kext
4. AMDSupport.kext

boot with -v, and loading 1 or 3 needs 4.

• load nothing: running with Apple's framebuffer
• load 1: not boot, stop at verbose messages
• load 2 only: kernel panic by the WindowServer, saying "a freed zone element has been modified: expected 0x58a9ed316bd0202 but found 0xbfbfbf00bfbfbf, bits changed 0x535216c1602bdbd, at offset 0 of 96 in zone: namecache"@/SourceCache/xnu/xnu-2422.115.4/osfmk/kern/zalloc.c:461"
  oooo .... malloc/free not matching ...
• load 3: just like loading nothing ... -- name the framebuffers with correct name and address.
• load 4 only: just like loading nothing ... -- only load (?)
• load 1, 2, 3: like `load 1', stop at verbose messages
• load 2, 3, 4: no kernel panic now, but Window Server crashes with SIGILL and repeatly restart itself
• load 1, 3, 4: mmm ... I forget it ...
• load 1, 2, 3, 4 (all): our familiar `white screen', fail to boot.

(by the way, I also faced a panic caused by vm_compressor ... I don't need to reboot if
this does not happen :(

from gmux-scripts.

well, the replacement cost is RMB 4612 (~ USD 740) since there are several expensive units on my logic board :( A whole replacement is too expansive ... so I'm now considering a new model without dedicated graphics

new intel iris pro seems ok :|||

from gmux-scripts.

Hi,
Has anyone successfully powered off the nvidia card? I am running Arch with a patched kernel on a Macbook Pro 11.3 but I just can't seem to drop the power consumption under 30W. Both cards are detected and "I can turn off" the nvidia card using vgaswitcheroo, at least that's how it's being listed, but judging by the power consumption and the temperature it not being powered down. Any suggestions? Thank you.

from gmux-scripts.

Hi,
I got my logic board repaired (replaced) free of charge after that Apple finally launched MacBook Pro Repair Extension Program for Video Issues http://www.apple.com/support/macbookpro-videoissues/
I don't know if it was fixed by with original parts or a revised one.

from gmux-scripts.

Anyone try this on the new AMD graphics based retina macbook pros? I do iOS dev, so I have to get a Mac, but it would be really nice to know if Linux could use the discrete card without too much pain...

from gmux-scripts.

Will this work with iMac mid-2011? Same graphic card, but not sure if GUID will be same or different? Can't check cause it doesn't even boot in recovery mode.

from gmux-scripts.