-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting switchable graphics to work on a macbookpro10,1 #1
Comments
Hi Victor, Great work! 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. 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, (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 andreas@heider.io) |
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 . 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. |
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! |
"the other patches are also on patchwork" 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. |
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 ^^ |
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? |
What a coincidence someone comments here, just the day I got switching to work! @orospakr 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:
after that switching works reliably with these two commands: switching to nVidia:
switching to Intel:
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. 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. |
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? |
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. 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.) 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. |
Gist updated with mutex, but untested atm. |
Here is another coder working on gmux: http://www.kevxu.net/2014/05/force-intel-graphics-on-2012-retina.html Maybe his findings can help you? |
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. |
Hi Drakulix, Could you provide your dmesg after intel card power on? Thank you for the great work! |
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. |
Thanks! 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: |
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. |
I'am using nouveau+intel. I thought that it is even not possible to use nVidia blob with efi kernel. |
Latest |
Hi everyone!
Thank you for the great work! |
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:
|
Hi Andreas, |
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.
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. |
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. |
@ah- I agree that we should boot via EFI and your explanation with the exit boot call makes sense. 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 |
What did you need to fix for 3.18? 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. |
@0xbb: Of course, feel free to write me at andreas@heider.io 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. |
@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:
|
@0xbb |
@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 ;) ) |
@Drakulix Ah ok, I thought you have a Macbook Pro 11,3 too. Could also give me your current commands for switching between the GPUs? Btw, has anyone already found out how gfxCardStatus permanently switches the GPU? It would be nice to reproduce that behavior under Linux. |
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
|
@sprin thank you very much for your report and testing gpu-switch! For your burning legs you could try to switch off the discrete GPU with:
|
@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. |
@ah- , The system knows its previous failure, it will continue to try previous wrong settings :} 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:
The only changed feature is 'Dynamic Switching' , Disable Policy does not work. 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. I will try later since the recovery from every single wrong setting may cost much time ... |
Hi There, Am I missing something ? please advice. Thank you all for this great progress. |
@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:
And then run |
Actually, the steps should be:
|
Hi, Is there a way to disable completely the switching to failing discreet GPU ? Thanks |
@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. |
It's intermittent now, after some reboots it detect the discreet GPU and sometime it doesn't. I am looking for a way to completely disable the failing discreet GPU. |
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: the brief procedure:
|
@przhu Same here, the cost for replacing the logic board was 570 Canadian Dollar. That is why I am looking desperately for a permanent fix. |
Hello everyone, Will the same command I'd like to try it but assuming it works I have a couple questions:
Thanks a lot. |
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. |
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) |
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. |
well gpu-power-prefs does not work with mine :( if I removed all AMD/ATI drivers, the system can boot and treat my screen as so I'm now interested in selectively enabling drivers. |
I have a 6750M (but now the system says it is 6770M ... the same, only clock rate difference), related drivers are:
boot with -v, and loading 1 or 3 needs 4.
(by the way, I also faced a panic caused by vm_compressor ... I don't need to reboot if |
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 :||| |
Hi, |
Hi, |
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... |
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. |
Dear Mr Heider,
I have spend the past days making research on the situation about getting vga_switcheroo to work on newer macbook pro's, and your patches and scripts seem to be the only progress that was made on this subject for a long time.
I am sorry for creating an issue here to contact you, but I was not able to find an email address.
So first of all I am using a macbookpro10,1 (which is the first retina macbook pro 15" with an Intel HD 4000 and a nvidia 650m). I know, that your patches were supposed to work on another (older) generation, I just try to get some help on this subject. I spend already quite some time trying to fix this on my own.
So the starting situation is quite similar. I have loaded the i915 module and nouveau (no attempts yet to use the nvidia blob) and the system boots via EFI using the nvidia output according to switcheroo. Switching to the Intel chip just makes the screen black, but keeps the system running. I can get back to the nvidia chip (blindly or via ssh), but the console is not displayed anymore (I am running a minimal arch linux without any X Server currently for testing ), but the screen gets lid again upon switching, so it seems to detect the output display again.
After taking a look at all your patches I noticed that the apple_gmux module has already been adopted and updated for the new gmux of my macbook and that the structure is still quite similar to your module.
I also noticed that neither your rom_window patch, nor your i915 hack seem to have made it into the kernel, so my first attempt was rewriting those for a recent kernel (3.15.6).
This is my patch file: https://gist.github.com/Drakulix/d3013d7834db53f04b2f
This one still contains some typos (dcc instead of ddc) and is broken, because the clients are not stored in an array, but a list right know (easy to fix). I am on the wrong system to upload my latest (working) patch right now, but it should give you an idea, what I am trying to accomplish.
Also I have not attempt the convert the nouveau patch yet, because the structure of the driver has changed quite much and it should not be necessary for a successful switch to the Intel chip. (My goal is still complete support, not just using the intel chip.)
Sadly this patch does nothing. It applies and compile correctly (, well my latest version does), but the behavior is unchanged. The i915 driver is still not detecting my integrated display correctly (at least that is what it seems like).
I also have to admit, that this is my first experience with kernel patching, so I have no real idea, how I could start debugging this. I am used to unix and linux, but I have no yet installed a productive linux system on my macbook, because not being able to switch the graphics is an absolut deal breaker for me. However I am totally willing to get my hands dirty on this and any hints, where to start, are more then welcome.
Greetings,
Victor Brekenfeld
P.S. I think I have found some hints, that your location might be germany, while reading through the mailing list, etc. If thats the case and you can speak german, that might be better for understanding each other. My first language is also german, but my english is quite rough.
The text was updated successfully, but these errors were encountered: