ktbos

I'll post back if I make any improvements in the Audio. But today was more work on the Video. I had previously reported that PlatformID 4 is the one that got my computer to boot with AppleIntelFramebuffer working. But after some testing today, I realized that was only really by accident. PlatformID 4 has only one port, the internal display, so I think it worked because it didn't have any settings that were incompatible. But given the specs on PlatformID 4, it didn't match the capabilities of my laptop like PlatformID 3 did. So I switched back to PlatformID 3 in my boot plist and did a hex edit on Framebuffer to get it to work. (Had to change one bit from "02" to "00".) I continued with more hex edits to Framebuffer as detailed in the HD4000 post to get the HDMI working with Audio and then made the recommended DSDT edits to get that working too. That works very nicely. Though most of the time I won't be using HDMI - either the laptop alone or the laptop docked. DVI output from the port replicator seemed to work without any modifications. Booting up with the laptop docked, everything works great. Booting up with it undocked and then docking gets you an extended display, though; even if you close the lid/display, it still thinks the internal display is the main display. I suppose you could set up mirroring but I don't think the internal display would know to go off. And then there is booting up with it docked and later undocking: you lose the display and can't get it back without a hard shutdown. I know the genuine Apple hardware doesn't have the notion of docking but is there a way to improve the handoff control? I was unable to get the VGA output working as a discrete port from the internal display. (Careful readers may recall me previously saying I didn't have a VGA port on my laptop - sorry for the goof earlier.) I think the VGA output is tied to the internal display somehow. In fact, when you use the Fn-F8 key combo, you can switch to the VGA connector. Although I wouldn't recommend it since it is garbled and confuses the hell out of MacOS since the MacOS was unaware that the video would be changing to a completely different object. And the fact that VGA doesn't work well with HD4000 isn't too surprising since I don't think Apple sells any hardware with HD4000 and a VGA port. I'd like to get all this working a little better so any suggestions are appreciated. I'll add my Framebuffer kext and my DSDT here after any edits to get things working better. (I'm being optimistic!)

My Dell E6430 laptop is now working with internal display, external HDMI, and DVI through a port replicator! A couple of comments on the guide: First, I believe the reference made in this guide about "rev 09" is incorrect. While I do have "rev 09" on my "0166" device (as shown by lspci -nn), my platform ID for Framebuffer is actually "3". So it may be true that a majority are rev 09 but I don't think that helps with the platform selection - you just have to do trial and error to get it right. 3 is a good start since it supports 4 different ports. See this post at insanelymac for details on the different platform IDs. Next, this guide only discusses 3 possible ports, but some platform IDs, including the one for mine, actually support 4 ports. So in the the guide above, just go one line of Hex further than the examples shown if you are using a 4 port platform. I was unable to get VGA working alongside the internal display. I think that they may be internally linked in my laptop. In fact, using the Fn F8 key combo switches between them. It's pretty ugly display and then it promptly breaks, though. So probably not wise to use. But perhaps not too surprising since I am not aware of any Apple laptops that have HD4000 and a VGA port. I'd be interested to know if anyone has actually been able to discretely get the VGA and internal displays working independently. Now for my port replicator, if I boot up in the port replicator, everything works great. If I try to dock into it with the computer already booted up, the Hacintosh thinks it is going for extended displays instead of switching the internal display off. Even if I close the lid/display, the display stays lit and extended display is active. And the worst is if I try to undock after booting up with it docked - no switching to internal display which means I need to force a reboot. So there's some handoff issues that would be nice to figure out. And just to confirm, I was able even to get the HDMI audio working using the combination of this post and the one about patching AppleHDA binary. And while I don't expect to do that often (most of the time either laptop on the road or in the office docked), it is very cool that I can do that. UPDATE I forgot to check both DVI on my dock. I checked today and both work at the same time! I can't yet tell if either are working with Dual-Link DVI (since I don't have a device that requires dual-link - yet!) but very excited to have both displays working well. If I could get the docking and undocking actions working well, this would be perfect. /UPDATE

I've gotten the audio controls working better. I made some changes in the Platforms.xml file of AppleHDA. Here's my version: AppleHDA.kext.zip Give it a try, Jake, and let me know if it improves things for you. Details on what I did are in the AppleHDA thread. It's still a 10.8.2 version. I tried using 10.8.4 and making all the changes myself but apparently, I didn't get it completely right and the result was no audio at all. Oh well, good thing the 10.8.2 version still works - and hopefully will for 10.8.5 too. Volume could be a little louder on both speaker and headphones. My tests were loud enough but not so loud that I'm confident that I'd be able to hear things with low source volume. If anyone has suggestions on how to tweak the AppleHDA to improve that, let me know. (And yes, I've asked the same on the AppleHDA thread.)

I've made some great progress. Only minor edits got the volume controls to remain in sync and the volume scale to be fully functional - at least on the internal speakers. (The headphone scale is debatable but it's close enough, I don't think it is worth worrying about.) I did use the codec verbs I had put together from my earlier post in this thread and applied the data to AppleHDAHardwareConfigDriver.kext/Info.plist as described in AppleHDA Binary Patching. I'm not sure if that made much difference, though. The data was pretty similar to what was already in there but there was some additional data. That may be useful when it comes time to work with dock audio output (which I have not tested since I don't have the dock working at all now). I think what made the bigger difference was the changes to Platforms.xml. I updated the path map for the main internal speaker output to include a mixer and a selector. And I moved the amplifier definition from the output node to the selector node. When I put that back to the way it was in the E6430 Guide's AppleHDA, the problem I was trying to fix return. When I make the changes described here, the problems go away. So I'm pretty confident that the Platforms.xml change is the trick that gets it working. Attached is the updated AppleHDA kext: AppleHDA.kext.zip Note that I did try to make the changes on my original AppleHDA.kext from 10.8.4. I figured it would be better if I could make the changes new so I could do them on 10.8.5 and then again for Mavericks. But I lost all audio when I made the changes. There's a lot of seemingly inconsequential differences between 10.8.2 and 10.8.4 files (most seemingly due to sequence of objects) but obviously something I deemed inconsequential was actually quite consequential. No idea what it is and since the 10.8.2 kext is working, I'll move forward with that. The lingering question I have is if there is a way to boost the volume. Max volume is now loud, but I'd like it to be louder for those inevitable videos that have a source volume too low. I've been monkeying around in Platforms.xml, the layout12.xml, and in the Info.plist for AppleHDAHardwareConfigDriver but I got nowhere. So if anyone has suggestions on how to increase the volume, please reply and let me know! (And if I do get that, I'll update the kext attached above with those changes.)

It's Jake's from his Guide. Which is one I believe you patched for him. Presumably a 10.8.2 one. (Note that it didn't work in myHack.kext, though. I had to move it directly to S/L/E to get it to work.) And by "working", I get sound, but the controls don't sync and the volume scale isn't right. I don't know if these issues are controlled from the layout, from the binary, in the DSDT, a combination, or somewhere else. So I figured I would follow your guide from start to finish and find out where I ended up - see how my HDA behaved differently from the one in the guide. And since I'd be starting with a 10.8.4 Apple original, that seemed like it stood a better chance of working well. Also, I'm going to be using the laptop docked in the E/Port Plus with USB 3 so the ability to get audio through the dock will be important too. So, let me know what you think - is the HDA I have as good as that will get and my issues need to be resolved in something other than the HDA? Can the HDA patching be improved to fix my issues? Is that patching something I should be able to do given the files I attached with some additional guidance or is it better left to a true expert? Finally, I described the audio issues and how I got audio working at all with the Guide's AppleHDA.kext in this post of the E6430 ML thread.

Thanks. And for what it's worth, I believe Jake said he's having the same issues with audio on his E6430 so hopefully more than just me will benefit from some improvement in the HDA.

Here's what I've come up with so far: ktbos_codec.zip The codec_dump file is exactly as described in this post. And the codec_data file is following along the steps in the post. For me, things went pretty smoothly following the steps in Post 1 of this thread. The paths in my codec_dump were not nearly as logical as in the example, though. (for example, the line-in pin had the asterisk connection for the speaker main volume which can't be right) So I needed to spend a little more time piecing together what would probably make the most sense. I'm using a Dell E6430 and the DSDT from Jake's guide. Here's my lspci output line for the audio device: 00:1b.0 Audio device [0403]: Intel Corporation Panther Point High Definition Audio Controller [8086:1e20] (rev 04) I do have audio working (after putting the AppleHDA kext directly in the S/L/E because the myHack one was causing kext errors and failing to load) but it's got some issues. Primarily that the volume controls in the prefPane, in the menuBar, and the keyboard buttons don't stay in sync with each other. And since the kext was from 10.8.2, I figured it might be time to run through the full set of steps and make a new 10.8.4 one that hopefully didn't have the control sync issue and maybe made better use of the volume range. Alternatively, if you have a suggestion for how to fix the sync issues and make other tweaks to improve the operation of the audio kext, I could start with the AppleHDA from Jake's guide and modify that. (and/or DSDT modifications) Thanks!

For anyone interested in all of the different layout files and what vendorID they correspond to, here's a crude mapping I created (pasting it inline instead of as an attachment so it is searchable: (in a few cases, there are extra vendorIDs after the filename - apparently those files have multiple CodecIDs in them, and therefore multiple VendorID) file = layout0.xml, VendorID = 10134206 1aec8800 10ec0885 10de0007 10ec0262 file = layout1.xml, VendorID = 10134206 file = layout10.xml, VendorID = 83847680 file = layout11.xml, VendorID = 10134206 file = layout12.xml, VendorID = 10ec0885 file = layout13.xml, VendorID = 10134206 file = layout16392.xml, VendorID = 10134206 10de0007 file = layout16394.xml, VendorID = 10ec0885 file = layout17.xml, VendorID = 10134206 file = layout18.xml, VendorID = 10134206 file = layout19.xml, VendorID = 10134206 file = layout2.xml, VendorID = 83847680 file = layout20.xml, VendorID = 83847682 file = layout21.xml, VendorID = 83847680 file = layout24.xml, VendorID = 10134206 file = layout27.xml, VendorID = 10134206 file = layout28.xml, VendorID = 10134206 file = layout29.xml, VendorID = 10134206 file = layout3.xml, VendorID = 10134206 file = layout31.xml, VendorID = 10134206 file = layout32.xml, VendorID = 10134206 file = layout33.xml, VendorID = 10134206 file = layout35.xml, VendorID = 10134206 file = layout36.xml, VendorID = 10ec0885 file = layout38.xml, VendorID = 10ec0885 file = layout39.xml, VendorID = 10134206 file = layout4.xml, VendorID = 83847680 file = layout40.xml, VendorID = 10134206 file = layout42.xml, VendorID = 10ec0885 file = layout44.xml, VendorID = 10ec0885 file = layout46.xml, VendorID = 10ec0885 file = layout48.xml, VendorID = 10ec0885 file = layout5.xml, VendorID = 10134206 file = layout50.xml, VendorID = 10ec0885 file = layout53.xml, VendorID = 10ec0885 file = layout56.xml, VendorID = 10ec0885 file = layout58.xml, VendorID = 10ec0885 file = layout59.xml, VendorID = 10134206 file = layout60.xml, VendorID = 10ec0885 file = layout61.xml, VendorID = 10134206 file = layout62.xml, VendorID = 10ec0885 file = layout63.xml, VendorID = 10ec0885 file = layout64.xml, VendorID = 10ec0885 file = layout65.xml, VendorID = 10ec0885 file = layout66.xml, VendorID = 10ec0885 file = layout67.xml, VendorID = 10ec0885 10134206 1aec8800 file = layout69.xml, VendorID = 10ec0885 file = layout70.xml, VendorID = 10ec0885 file = layout71.xml, VendorID = 10134206 file = layout72.xml, VendorID = 10ec0885 file = layout73.xml, VendorID = 10ec0885 10134206 1aec8800 file = layout74.xml, VendorID = 10ec0885 file = layout75.xml, VendorID = 10134206 file = layout76.xml, VendorID = 10134206 file = layout77.xml, VendorID = 10134206 file = layout78.xml, VendorID = 10134206 file = layout79.xml, VendorID = 10134206 file = layout80.xml, VendorID = 10ec0885 file = layout81.xml, VendorID = 10134206 file = layout82.xml, VendorID = 10134206 file = layout83.xml, VendorID = 10134206 file = layout84.xml, VendorID = 10134206 file = layout85.xml, VendorID = 10134206 file = layout86.xml, VendorID = 10134206 file = layout88.xml, VendorID = 10134206 file = layout9.xml, VendorID = 10134206 file = layout90.xml, VendorID = 10134206 file = layout91.xml, VendorID = 10134206 file = layout92.xml, VendorID = 10134206 file = layout95.xml, VendorID = 15ad1975 file = layout98.xml, VendorID = 10134206 file = layout99.xml, VendorID = 10134206 To do this, I had to uncompress each of the xml files. The OP makes mention of the zlib.pl file but it isn't attached to this post, so I'm adding it here: RevoGirl's zlib.pl script: zlib.pl.zip Also, for anyone interested, here's what I did to get this data: First, uncompress each of the XML files: for file in *zlib; do base=$(echo $file | sed "s/.zlib//") perl /path/to/zlib.pl inflate $file > $base done Then get the CodecID and convert it to Hex: for file in layout*xml; do printf "file = %s, VendorID = " $file grep -A 2 CodecID $file | grep integer | sed 's/^.*\<integer\>//' | sed 's/\</integer\>//' | sed 's/ *\<\!.*\>$//' | xargs printf "%x\n" done > vendorID.txt

Hi,EMlyDinEsH, I've been working on following this guide for about 5 hours now. I've managed to get through all the steps up to editing the XML. I got stuck when you mentioned the attached zlib.pl file since I can't find any attachments to your post! (Am I missing it?) I was able to find it on one of your linked pages so i could keep going. Now I am trying to follow your instructions for editing my own XML file. But I'm not sure what to do with that pile of verbs I have created in Part 3. Your guide doesn't mention where they go! I thought maybe I would be able to figure out where they go by looking at the file you describe having produced but again, I can't find that attachment either. Hopefully you can fill in the missing pieces for me so I can wrap up the AppleHDA patching. Thanks!

Update on Audio: Forget what I wrote above about the Audio and Video being tied together and maybe problems with one are related to the other. I removed the original AppleHDA.kext from S/L/E. Then I moved the bootpack AppleHDA.kext from Extra to S/L/E. I ran myHack myFix Quick and rebooted. Audio mostly works now. And no complaints about kexts that couldn't be loaded. Is it possible there is a problem with the latest version of myHack and kexts that have nested kexts in them? If it is the same kext as was in Extra but now it is working in S/L/E that means there must be something procedural causing the error messages I was getting? But Audio is only mostly working. I can adjust the volume in the pref panel successfully but only the top 75% of the slider is audible - you get to effectively mute at about the 25% mark. The icon in the menubar does not update when you update in the pref panel The slider from the menubar does not update when you change the pref panel When you update the menubar slider, the pref pane slider updates on the second change If you use the audio keyboard buttons (actually next to the keyboard but effectively still keyboard buttons), volume down always goes one notch down from max and volume up always puts it at max, regardless of what it was before Is this list of issues commonplace with the modified AppleHDA or unique for my computer? Any known fixes? Do we know where the modified AppleHDA came from and what modifications were made? Is it possible that the changes are for an earlier version of MacOS and need to be updated for my 10.8.4? I can start with the latest 10.8.4 original AppleHDA kext and make modifications if there's any knowledge about what was changed in the bootpack one or what should be changed. I found this article about patching AppleHDA but I don't want to start down that process if there are easy fixes or tweaks or a better place to start.

That's an understatement!! Thanks to you and Hervé and Bronxteck for generating the ideas that got me to the solution. Yeah, that's interesting. Especially that the video card is the same - same ID and same rev number - and yet for some reason we needed different PlatformIDs for the Framebuffer. There must be a good reason for that, I would love to know what it is. I moved the Bluetooth and the SD kexts out of the Option folder and into the main Extensions folder back at the beginning of my process. So they are in the myHack.kext. In fact, you can see the error from the Bluetooth one in my post. There is no error about the SD kext, which must be loaded since it is causing the error you mention. And yet it doesn't recognize the SD device. All the trouble with none of the benefits. I'm going to need to look into details on the Bluetooth and SD device another time. Thanks for the summary about the trackpad. I tend not to use the scrolling so much in Windows but was willing to give the Mac method a go. But I'd have no patience for needing to reset the z value on every boot nor any other weirdness. Hopefully somebody has the time to get that working well. (Wish I had the time and the knowledge!!) Audio is definitely not working at all. This is the one that is most perplexing right now. No, I didn't remove anything else from your DSDT other than what I pasted above. And yes, it compiled fine. Is there something in what I deleted that maybe I shouldn't have? I vaguely remember when I did a safe boot, before video was working, I got a slew of myHack kexts that failed and I'm pretty sure all the HDA/Audio ones were in that batch. I chalked it up to being in Safe Mode and indeed when it began working in not-safe mode (danger mode!?), there were fewer failures. So that would have been with your DSDT unchanged and with your Framebuffer kext when it wasn't working for me. And yes, your device ID is identical to mine. I suppose since it is wrapped up in the display driver and our hardware IDs match there but we needed different drivers, it shouldn't be too surprising that Audio is following a similar pattern. Ugh. Again, great info. Thanks! I'll get the order out for that shortly.

Okay, with the safe mode boot problems behind me, I can finally get back to getting this thing fully operational. The Trackpad and stick work well with basic functions. All 5 buttons seem to work. (The middle button on the upper row above the trackpad appears to be a clone of a left button.) But I don't have any advanced functionality. The Guide states that it might be possible with the Trackpad code linked there but I'd be interested to know what the latest is for the E6430 - and @Jake Lo, specifically. Audio is completely not working for me. There are no output devices in the Sound pref panel. And after my first boot, I got a series of errors about kexts that couldn't be loaded: The system extension "/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleHDAHardwareConfigDriver.kext" was installed improperly and cannot be used. Please try reinstalling it, or contact the product's vendor for an update. The system extension "/System/Library/Extensions/myHack.kext/Contents/PlugIns/IOBluetoothFamily.kext.kext" was installed improperly and cannot be used. Please try reinstalling it, or contact the product's vendor for an update. The system extension "/System/Library/Extensions/myHack.kext/Contents/PlugIns/IOHDAFamily.kext" was installed improperly and cannot be used. Please try reinstalling it, or contact the product's vendor for an update. The system extension "/System/Library/Extensions/myHack.kext/Contents/PlugIns/AppleHDAController.kext" was installed improperly and cannot be used. Please try reinstalling it, or contact the product's vendor for an update. The system extension "/System/Library/Extensions/myHack.kext/Contents/PlugIns/IOBluetoothSerialManager.kext" was installed improperly and cannot be used. Please try reinstalling it, or contact the product's vendor for an update. Yes, I ran myFix and most of the kexts worked, so I don't think this is a procedural issue on my part. Also not working is the Bluetooth, as you can see from the above messages too. Also, the card reader is not working. @Jake, it might be helpful if in your guide, you show the results of an lspci? It would make it so those of us that want to follow the guide will have a better idea if our hardware is a match or if we are likely to need to do some tweaking. If not, can you reply with the lspci here? Or at least include details on your audio device(s) and your bluetooth? And your card reader? The other nit I have now is every time the computer boots or wakes from sleep, I get a note about the Win7 drive not being readable and should I initialize. It would be great to make that go away so I don't have to answer it every time. I remember reading somewhere that including the card reader kext would cause messages like this but I thought it was about the card reader, not about other hard drives. And considering that the card reader isn't even working, I'm not sure it is related. Can someone fill me in on WiFi? If I were to get the DW1510 that is widely discussed in this forum, WiFi would suddently come to life without any further hacking or kexts? And the one I have now is not operational on Hacintoshes?

According to Micky1979 at InsanelyMac, the version has nothing to do with the platform ID. So there is no way to tell what platformID you have. The only way to figure it out is trial and error. And if you are like me, you'll test the numbers in some haphazard way and discover that the one you want is the last you try! As I posted above and as Jake mentioned, you do need to pull out the DSDT patch in Jake's bootpack's DSDT. The method I included above is the one to remove. You will also need to remove the AppleIntelFramebuffer kext that you may have added per the Jake's guide. I added the following lines to my boot plist file (not sure if they are needed, but it works with them): <key>GraphicsEnabler</key> <string>Yes</string> <key>VBIOS</key> <string>Yes</string> Then when you boot, tab to the text screen and enter -v IntelCapriFB=# where # is all of the numbers from 0 to 11, inclusive. For me, '4' worked. And it was the only one that worked for me. Other values either did nothing (and therefore switched to the black screen as though Framebuffer kext wasn't be used at all) or gave me the text hang that I started posting about in this thread. Once I had that platformID figured out, I added the following to my boot plist: <key>IntelCapriFB</key> <string>4</string> No more safe mode boots for me and graphics look very nice with a transparrent menubar and HD4000 reported in the System Report. Also, I should point out that earlier I was asking about when I could do a Quick myFix since the Full took so long. (I'd still be interested in the answer to when to use Full vs. Quick.) But I discovered that my USB drive is amazingly slow. The Full myFix on my 16Gb USB drive takes more than 10 minutes. The Full myFix on my 350 Gb HDD partition takes 1 minute. SanDisk Cruzer Glide should not be used for booting disks. (My USB install drive is a Patriot and is at least 10 times faster on these kinds of operations.)

Yes, USB 2 port on the left side. (That was one of my early challenges!; solved before posting here) Ah, okay, so how would I go about removing the video patch in DSDT? I compared the GFX section of the DSDT I made for my laptop with the one from the guide. I found an additional method there: Method (_DSM, 4, NotSerialized) { Store (Package (0x08) { "AAPL,DualLink", Buffer (0x04) { 0x01, 0x00, 0x00, 0x00 }, "AAPL,ig-platform-id", Buffer (0x04) { 0x03, 0x00, 0x66, 0x01 }, "hda-gfx", Buffer (0x0A) { "onboard-1" }, "model", Buffer (0x17) { "Intel HD Graphics 4000" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } Is this the method that should be removed? I tried removing it and putting it on my USB test stick. I still had the special Framebuffer kext removed so it was using the S/L/E Framebuffer kext. I've updated the boot plist now to include the flags I was putting on the boot line yesterday so now my boot plist looks like this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>DSDT</key> <string>/Extra/DSDT.aml</string> <key>DropSSDT</key> <string>Yes</string> <key>EthernetBuiltIn</key> <string>Yes</string> <key>Graphics Mode</key> <string>1600x900x32</string> <key>Kernel</key> <string>mach_kernel</string> <key>Kernel Flags</key> <string>-f npci=0x2000 darkwake=0</string> <key>SMBIOS</key> <string>/Extra/smbios.plist</string> <key>SystemType</key> <string>2</string> <key>Timeout</key> <string>1</string> <key>USBBusFix</key> <string>Yes</string> <key>UseKernelCache</key> <string>Yes</string> <key>GraphicsEnabler</key> <string>Yes</string> <key>VBIOS</key> <string>Yes</string> <key>IntelCapriFB</key> <string>3</string> </dict> </plist> I'm starting with "3" because that's what Jake had used in his version of the Framebuffer. I figure if I can at least reproduce the same behavior I was seeing with the custom Framebuffer through the new Chameleon tool, then I know I've got something having an effect. Unfortunately, testing so far shows I get the same results that I would if I didn't have the Chameleon IntelCapriFB working - without the Guide's custom Framebuffer, I get the black screen when it should be going to the login. And I'd expect to see it hang with the text like it did when using the custom Framebuffer. I was not able to produce the hanging effect but I completed my testing and found that ID=4 got video up. I still need to do more investigation, but this is big progress. I'll report back with a new post when I have more figured out. (Note that according to this post, this ID should not have worked for me since the VRAM is 64 in the BIOS but ID 4 is 96. Also, lspci reports that I have rev 9 of 0166 which should translate directly to using ID=9 in the Chameleon bootloader. That's why checking "4" was one of the last things I did. So something isn't working there either.)

Again, Jake, you and I were reading similar things. I was looking into the idea of different PlatformIDs when your post came in. Then I was trying to figure out how to change the PlatformID when Bronxteck's post came in... Bronxteck, that was great timing. And great timing for the Chameleon team to be doing that too! So I switched gears and I've been working on using Chameleon since you wrote your post. But I still couldn't get it working. Here's what I've done: - install new version of Chameleon 2262 on the USB test stick - reinstall the Extra folder from the Guide - added the Framebuffer kext from the Guide for 10.8.4 and rename it - modify the boot plist to boot with 1600x900x32 - install Extra to the USB test stick using myHack - ran myFix, Full on the USB test stick First I booted from the USB test stick to confirm it was still hanging as before. It was. Then, I booted from the USB test stick and hit tab to get to a boot prompt where I typed -v GraphicsEnabler=Yes VBIOS=Yes IntelCapriFB=# where # is every number from 0 to 11. I started with 3, then tried 8 and 9, then getting more discouraged, I tried the remaining choices. All twelve resulted in the same hang as I've gotten before. That's especially surprising since one of the pages mentioned that if you use an option with the wrong VRAM, you'd be likely to get a kernel panic but the options didn't seem to have any effect at all - nothing blowing up, nothing working; just the same hang. After adding the VBIOS flag, I could see Chameleon printing something out about the video but it scrolled by so quickly I couldn't read it. And I don't know of a way to pause or log the Chameleon boot. From looking at the Chameleon help, it looks like IntelCapriFB is only used when VBIOS is set to Yes (indented options). And the boot plist file doesn't contain that or the GraphicsEnabler. I added GraphicsEnabler=Yes and VBIOS=Yes to make sure I covered my bases. Did I miss any steps with the Chameleon change? The fact that I couldn't see a difference, good or bad, was discouraging and made me wonder if it was working. But the fact that the VBIOS addition did print something right after hitting enter makes me think it was acknowledging at least that input. Since Chameleon 2262 didn't seem to be doing the trick, I am back to Jake's idea about editing the Framebuffer kext. I can do the hex edits, but I'm fuzzy on what exactly I'd be changing. I see where the post shows using ID 03 and I can see the differences from the original ID 03. But how would one know what changes to make there? Jake, you mention that the ID 03 has been working or you, but I'm not clear on what change, if any, you made in your copy of Framebuffer or how you determined it gave you the best results. Were the Framebuffer kexts from the Guide modified per this method previously? Was there any more than this change made to the Framebuffer kext? If I make changes per this hex edit method, should I start with the 10.8.4 kext from the Guide or should I start with the Framebuffer kext from S/L/E? I also tried removing the Framebuffer kext from the E/E and rerunning myFix, then repeating the tests with the IntelCapriFB Chameleon option. All of those tries resulted in the same black screen that I get without the Framebuffer kext and without any special Chameleon options. In other words, IntelCapriFB had no impact this way either. I'm not sure if the IntelCapriFB boot option should override the custom kext installed by myHack or if it needs to work with the stock one in S/L/E but at least this way I've tested both ways. Oh, and while I don't have a spare HDD, I can try reinstalling to the same HDD I plan to use in the long run. I can't boot from it yet (because that would require making the Ubuntu and Win7 partitions unbootable which I'm not ready to do yet), but I can boot from the USB stick and select the HDD as the boot volume if you think that would be a useful test.

Jake and Hervé, before going on with debugging info, I wanted to thank you both for all of the great information. It isn't fixed yet, but rather than thank you exclusively for a fix (which I still hope to be able to do!), I wanted to thank for you all the time you have taken already to do the debugging. I'm liking it here at OSXLatitude already. No difference in the DSDT? Oh, that's really useful info. Thanks. Is there a difference for CPU? I think Hervé had said he didn't think there was. That would mean the DSDT you have in the guide should work fine for me despite the different specs? Jake, thanks for checking the BIOS version. Good to know we don't have a BIOS compatibility issue. I have not reinstalled throughout any of this debugging. I've only been modifying the USB test stick's boot characteristics. (And therefore not changing the USB install stick at all.) So yes, myFix has been run (now, properly!) on the "system" - what I am calling the USB test stick. (I haven't even put the hard drive back in the laptop while I've been doing all this testing.) Here's the Video section from my BIOS Settings / General / Stystem Information: Video Controller = Intel HD Graphics Video BIOS Version = 2158v12 Video Memory = 64 MB Panel Type = 14.0" HD+ Native Resolution = 1600 by 900 "on what connector your display is"? Oh, does that mean there are different vendors for display and mine may be different from yours? Does our Video BIOS match and if not, does that get updated along with the computer BIOS?

Jake's specs as posted in his Guide: BIOS A11 | i5-3320M 2.6GH | 4GB DDR3 | Intel HD 4000, 1366x768 And mine as summarized from my BIOS txt: BIOS A12 | i7-3520M 2.90GHz | 12 GB DDR3 | Intel HD 4000, 1600x900 I didn't know that CPU wouldn't matter for DSDT. But since his display is different, and since that's what I'm chasing after here, I would have assumed that was enough for it to mean it shouldn't work. Regardless, his *.aml files didn't work when I have tested his bootpack with no changes, even after adding the Framebuffer kext. It's the same result with the hang before the login screen.

I did try booting with an external HDMI display but as I expected, it doesn't ever switch over to HDMI. It is ignored from boot up through when it hangs. This model has no VGA output so I can't try that. Yes, the Intel HD4000 only. I didn't pay for the NVIDIA and it doesn't show under Windows or in the BIOS. (my BIOS: BIOS.txt.zip) Thanks for the tip on testing the myHack changes. So assuming I do have an issue with DSDT and/or Framebuffer, any suggestions on how to proceed? I'm all for trying changes to Jake's DSDT but wouldn't know where to start. (And note that there's more different between Jake's 6430 and mine than just the display rez.)

How about that. Safe Mode comes up fine at 1600x900 but I can't change it. Even after changing to Scaling, the only choice is 1600x900. At least something is behaving as expected... Thanks for that explanation, Hervé.

Jake, not only were we replying at the same time, but that's the next thing I was going to try! (In fact, I think I have tried it already but I probably didn't run myFix after it so that test would have been moot.) Here's what I did: - staged Extra directory using bootpack from guide (new copy to ensure no lingering junk from past attempts) - replaced dsdt.aml, SSDT.aml, SSDT-1.aml, and SSDT-2.aml in Extra with osxjeff's - added Framebuffer from guide using 10.8.4 version, renamed to AppleIntelFramebufferCapri.kext - modified boot plist to change resolution to 1600x900x32 - Used myHack to load Extra on to USB stick - Used myHack to run myFix, Full The result: hangs in the same place before login. Next for me to try is pulling out kexts one by one and see if I can get any further (even if something else breaks). Each time I do that, I'll need to rerun myFix. It is so slow to run Full, though. Any tips on when I should run Full vs. when I can run Quick? It would save me a lot of time if I could do Quick when making these changes. Or can I just remove the kexts from inside myHack.kext by deleting them from the file system under myHack.kext and then reboot with Kernel cache off?

Thanks for that info, Hervé. No, I had not been consistently running myFix. (And apologies to Jake for not picking up on what he meant in his last post.) I had been before, but I wasn't sure what it was doing or when I needed to run it, so I had gotten lazy and skipped it the last few times. But I had sat down at the keyboard to try figure out why there was no change (when there defintely should have been) so I was glad to read your post and realize quickly what I needed to do. I repeated the test now doing myFix after every change. With osxjeff's Extra, I get the hang as I have been reporting. Pulling the Framebuffer kext out and rerunning myFix made the screen go dark as it had the first time when I was following the guide and had not yet used the Framebuffer. At least I'm seeing changes now! And just to make sure that the Framebuffer kext was the right one (since I was just copying osxjeff's Extra and didn't know what version the kext was), when I put the Framebuffer kext back, I copied it from the 10.8.4 guide zip, renamed it, and then reran myFix. The result is the same hang before login. Recapping: - Following the Guide but using osxjeff's Extra gets me stuck before the login. - Not using the Framebuffer kext produces a black screen before login. - Running safe mode will get me in consistently I wonder if the black screen I get without the Framebuffer is an indication that I have gotten further or not as far. i.e. with Framebuffer it fails before the screen goes black perhaps because it is having a problem with the kext loading whereas when Framebuffer is not in there at all, it doesn't try to load it but then doesn't have what it needs to drive the display correctly. It's also interesting that safe mode works consistently. And now knowing that the way myHack works is to copy the kexts into myHack.kext and seeing all of those warnings about myHack not being loaded when in safe mode, I wonder if the reason it works in safe mode is because those kexts weren't loaded.

Jake, sorry I didn't get back to you right away yesterday - notification e-mails about post updates aren't coming through consistently. I'm using 10.8.4 and I chose the 10.8.4 kext version from the guide and renamed it as the guide suggests. Although I did just try a test removing that kext from the Extra/Extensions directory on the USB stick and booting with UseKernelCache=No and the result was the same as if I had it: hanging before login screen. I tried booting in Safe Mode again with the kext removed and it still worked the same as when the kext is in use. So that kext does seem like a likely cuplrit. Or maybe it's the DSDT/SSDT files aren't defining hardware that can be used by that FramebufferCapri kext? (Again, I'm using the exact Extra folder that osxjeff posted above with only the change for the boot plist that he described in the post immediately following to fix a typo. And then the changes I've described in my posts here in this topic.) Did everything look okay from my lspci output?

I've already got Chameleon 2.2svn. When I did the Chameleon reinstall, I did it from myHack 3.2 BETA 8. But I can see from the build number that it is a date later than the MyHack date, so I did the update. I needed to boot in safe mode using the USB stick so I could run Chameleon installer. Same result with the latest version of Chameleon (2.2svn-r2255). I was reading that in Safe Mode, Quartz Extreme is disabled; that's another sign that it may be a graphics-related issue. Here is a screenshot from System Report: SystemReport.tiff It's running in Safe Mode, so perhaps a kext would be used if it weren't in safe mode - in other words, the reason for the incomplete contents in the report may be due to Safe Mode, not that Safe Mode is the only thing usable because the report contents would be incomplete regardless of mode. When I boot in Safe Mode, after it has been up for a while, it reports "System extension cannot be used "for myHack.kext", then again for all the parts inside of it. Again, I wonder if the inability to use the kexts is because of Safe Mode or if it would happen in not-Safe Mode too.

Sure, that's easy and a great idea. Load Defaults and switch from RAID to AHCI. (CPU XD was enabled by default originally and I checked that it is still enabled after loading defaults; it is.) When I loaded defaults, it switched the display brightness level over what it had been all along - something I never played with and that gave me hope. Alas, no luck. Still hangs in the same spot with the same symptoms. Looking through the log again, I found "[AGPM Controller] unknownPlatform" - is that significant or maybe that happens all the time for those of you with E6430 working? Maybe AppleGraphicsPowerManagement could keep the graphics from activating?

Actually, the boot plist file from osxjeff's Extra doesn't have GraphicsEnabler in it at all. I'm not sure what the default is. So I have tried now both with a GraphicsEnabler=Yes and GraphicsEnabler=No and there was no change - both ways had the same result as not specifying it at all: hangs before the login screen. I don't believe the BIOS gives the option of setting the Video RAM. I looked again and I didn't see anything about that.