jpz4085

Yeah, I realize the screen corruption is very minor now so this isn't a big issue. From what I remember when I started out with the laptop any BIOS above A11 caused extremely severe issues on 10.11. That's what prompted me to look into this in the first place but later versions of macOS had almost no problems. I retained the patch because it eliminated the shutdown glitch. I've modified the WEG patches in my original post with what should be the minimum needed to implement them. I originally assumed existing WEG patches and didn't include the enable setting. The DSDT in the attached Clover folder provides an example. E6230-EFI-CLOVER.zip

I'd recommend trying the framebuffer patch below which completely eliminates the graphics corruption on my E6230. I came across it on another Hackintosh site some time ago and it was posted by a person with a different model Dell laptop that had the same corruption issue with an Ivy Bridge HD4000 IGPU. The post stated the issue is caused by an incorrect framebuffer memory size. Apparently for HD4000 based laptops it should be 8MB and not 16MB as defined in the AppleIntelFramebufferCapri kext by default. The post didn't provide a detailed explanation about exactly how this was determined and was several years old but it works all three versions I've used between A17 and A19 and probably others too. Clover KextsToPatch: <key>KextsToPatch</key> <array> <dict> <key>Comment</key> <string>HD4000 0x01660003 FrameBuffer 8 MB</string> <key>Disabled</key> <false/> <key>Find</key> <data> AwBmAQECBAIAAAAEAAAAAQ== </data> <key>InfoPlistPatch</key> <false/> <key>Name</key> <string>AppleIntelFramebufferCapri</string> <key>Replace</key> <data> AwBmAQECBAIAAAAEAACAAA== </data> </dict> </array> </dict> If using WhateverGreen.kext patching, add to Clover Devices/Properties: <key>Properties</key> <dict> <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <key>framebuffer-fbmem</key> <data> AACAAA== </data> <key>framebuffer-patch-enable</key> <data> AQAAAA== </data> </dict> </dict> Or to your DSDT file (along with the other properties) in the DSM method under the IGPU device: Method (_DSM, 4, NotSerialized) { If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) } Return (Package() { "framebuffer-patch-enable", Buffer() { 0x01, 0x00, 0x00, 0x00 }, "framebuffer-fbmem", Buffer() { 0x00, 0x00, 0x80, 0x00 }, }) }

@Narayan777, you might want to try the patch I posted here for use with the Dr. Hurt kext.

Hi @Hervé, I have more info to offer after experimenting with my DSDT and doing some research. Yes, my soft switch works with my wifi card in the other two slots. I thought it would as long as the card functioned in the slots. I downloaded the Sierra Pack from your D630 guide and compared the included DSDT to the one from my E6230. It is substantially different of course and the RBTN device doesn’t exist. I wasn’t able to identify anything that obviously applied to the wireless switch. I decided to see if my wireless switch would work OOB with different settings since previous attempts were unsuccessful. The Dell BIOS info for the E6230 states the wireless switch is controlled directly by the driver under Windows 8 which is what I’m using in the OSI “Darwin” checks. This is what the RBTN device supports. When I use Windows 7 or below in OSID the switch will enable/disable the WIFI/BT hardware directly which is probably the same way it works on the older D630. In order to use my wifi card this way I have to boot with the switch in the on position otherwise it remains disabled. This isn’t the kind of functionality I’m looking for since I’d prefer the switch to toggle the WIFI/BT power through the OS rather than enable/disable the hardware.

Correct but used in conjunction with the physical switch on the laptop rather than a key on the keyboard. With the above solution in place you can slide the switch to toggle power for both devices. I assume it's working that way for you? The LED is just cosmetic but I like to see it on when the BT/WIFI is enabled. Only by invoking the soft switch without which it won't do anything except produce an F17 key press. The physical switch can't do anything without some sort of software interface. I don't have any cards for the expansion slots so I can't test that but odds are the script can be modified to accommodate them if it doesn't work.

The purpose of this post is to provide a solution for anyone who might want to use the wireless switch on this model of laptop. It will enable toggling the wifi and bluetooth power (as well as wifi LED see Note 2) in a manner similar to Windows by using the switch. Download the attached zip file then extract its contents to a temporary folder and follow the instructions below. Configuration: Dell Latitude E6230 Laptop Dell DW380 Bluetooth Module (built in) Supported wireless card DSDT Patches: The following two patches are required. The first enables the switch ACPI notification by simulating Windows 8. The second will assign the unused F17 key through the VoodooPS2Keyboard ACPI keystroke function. Open your DSDT source file in MaciASL, click Patch and paste the code in the top section then click Apply and save the new DSDT file. Copy it to the Clover-ACPI-patched folder and restart. #Add Darwin check to Method OSID. into_all method code_regex If\s+\([\\]?_OSI\s+\(WIN8\)\) replace_matched begin If(LOr(_OSI("Darwin"),_OSI(WIN8))) end; #Use VoodooPS2Keyboard.kext ACPI keystroke function. into method label NRBT replace_content begin If (LGreaterEqual (OIDE (), One))\n {\n //Use F17 key for wireless switch\n Notify (^^PCI0.LPCB.PS2K, 0x0368)\n }\n end; Wireless Switch Support: Copy Wireless Switch Service.workflow to ~/Library/Services Open terminal and type: sudo cp blueutil /usr/local/bin Copy activate_services.app to a local profile folder of your choice. Add activate_services.app to System Preferences - Users & Groups - Login Items (See Note 1) Go to System Preferences - Keyboard - Shortcuts then click on Services on the left. Scroll down to Wireless Switch Service under General on the right then click Add Shortcut Click the wireless switch on the side of the laptop to add it as F17 Close System Preferences then click Finder - Services on the menu bar. The Wireless Switch Service should be displayed in the list. Click off the Services Menu without selecting anything and click the wireless switch again to test. Notes: activate_services.app is needed to automatically refresh the Services menu after logging in due to a long standing bug in Mac OS (detailed here) that prevents single key shortcuts functioning for Automator scripts. Without it the Wireless Switch Service won’t work until the menu is displayed. An additional feature when using the internal Dell Bluetooth module is the wifi light will come on if there is a paired device (such as a phone in my case) present in the Bluetooth settings. Bluetooth is enabled using Rehabman’s BrcmFirmwareRepo.kext and BrcmPatchRAM.kext on my system. This procedure can likely be adapted by others for use with other laptops that have either a wifi switch or hotkey. Credits: WiFi Toggle Service/Script: https://apple.stackexchange.com/questions/194368/turn-wifi-off-on-with-a-single-key Blueutil: https://github.com/toy/blueutil wireless.zip

Hi @Amoxitine , you'll definitely need to do a full instrumentation and identify the methods involved. The fact that the native brightness keys don't produce PS2 codes mean they only work through ACPI.

As far as I can tell by looking at the code in GPE _L13. Maybe something else is going on. All the Darwin patches look good and you're right there was none for WIN8 under _INI so that one might not matter. No. Fn+F3 and Insert will always work. The correct Darwin patches should cause the Fn + Up and Down control to work the same as Fn+F3 and Insert when my BRT6 patch is applied or not at all without it. Instrument them anyway. Anything that might be relevant. Try different windows versions in the _OSI checks and see what you get in the logs. Some method has to be called by the Fn + Up and Down keys if they work through ACPI. Alternatively they might be controlled directly by PS2 key codes. You could check that by downloading Rehabman's ioio utility, opening terminal and running it with ioio -s ApplePS2Keyboard LogScanCodes 1 and watching the output in the Console application in Utilities.

This is useful to know and actually sounds familiar; I think I had seen that at one point when debugging my DSDT originally. Judging from its code that GPE _L13 method is only SATA related and probably caused by hard disk activity. The other GPE methods don't look relevent either as far as I can tell. The Dell brightness keys will continue working through firmware (no macOS HUD) until the proper version of Windows is simulated in the OSI checks. Try adding Windows 2009/WIN7 and maybe Windows 2012/WIN8 to _INI and OSID respectively along with the ones already there. When patched properly the Fn+arrow keys will only change brightness through macOS when its running or not at all. The ACPI methods involved will only appear in the log when the brightness arrow keys are pressed and not any other keys. We can then trace the ACPI paths by manually instrumenting all the method calls in the last method appearing in the log. NEVT is an example of how to do that. You'll need to repeat that process from one method to the next until you reach one that doesn't go anywhere else. That's the one to which the brightness key patch applies.

Hi @Amoxitine , I made only the following two changes to your latest working DSDT. I added the second Darwin check and changed the BRT6 patches back to 0x0366/0x0365 as these are the only correct ones by default. I have made no other changes. See if it boots without issues and if the native brightness keys work. I’ve also included a second version with the ACPI debugging code added and _Q66 and NEVT fully instrumented. If you have issues try removing the second Darwin check and using the debugging code as a guide to trace the path through the methods. latest_with_debug.zip

I have a few suggestions to make. Remove WhateverGreen.kext as this might conflict with the IGPU patches and also remove CodecCommander.kext which shouldn’t be needed with AppleALC.kext. Remove ACPIDebug.kext until you will be instrumenting/tracing ACPI methods if needed. Put back my VoodooPS2Controller.kext, DSDT.aml and config.plist then rebuild the kextcache with sudo kextcache -i / and reboot. Check the Displays in the System Preferences and make sure the brightness slider is present and working. Then try the brightness keys. Other things to try if sleep/brightness issues continue include changing the Darwin patches in Method _INI and OSID to Windows 2009/WIN7 and opening config.plist in Clover Configurator going to Boot and set darkwake=no and restart and see what happens.

Hi @Amoxitine it's jpz4085 here, After reviewing your debug files I have made the following corrections. Your model’s DSDT is very similar to mine. I added the “Darwin” check under Method OSID you were missing. (Required for native brightness control.) I removed Device GFX0 and renamed Device VID (and references) to IGPU. That’s the correct one. I renamed Device ECDV to EC (and references) so USB power properties will load. (Not required but good to have.) I removed the XOSI hotpatches and SSDT as it’s unnecessary with the “Darwin” entries in the DSDT. I removed Intel graphics injection and audio layout ID from your config.plist as that’s already taken care of in your DSDT. Also you can remove the AppleHDA kext patches from your config.plist if you’re only using AppleALC.kext. I’ve included the source files for the native and patched DSDT for you to customize further if needed. Copy the attached files under EFI to the correct locations on your EFI partition and see how it works for you. Dell_E5430.zip

The one under _OSC was added by "OS Check Fix Windows 8" from the MaciASL Patch repo. I needed a Windows 8 patch for my wifi to work and that was where it put it. It appears I don't need that one as it's probably just USB3 specific and my wifi works fine with the one under OSID. Also all my USB ports work both before and after sleep with or without it so it's probably unnecessary.

Hi @Hervé, as you point out above I actually went through the process of instrumenting and tracing the ACPI Methods involved when I originally configured my laptop. I followed Rehabman's guides on his repo and elsewhere on the web. From the info I still have the exact sequence is (Q66 - NEVT - SMIE - SMEE - EV5 - BRT6) which only applies to the method under IGPU. For the sequence to reach BRT6 the OS Check Fix for "Darwin" has to be applied to the appropriate _OSI checks under both Method _INI and Method OSID otherwise the firmware will take control of brightness. The VoodooPS2Controller.kext driver has a feature originally implemented by Rehabman that can receive hex codes through ACPI and translate to PS2/ADB codes and associated functions. You can find more about it by searching the patch codes. I would have responded sooner but I had to dump the ACPI tables and go through the patching process to create a DSDT. I've been using Rehabman's hotpatch/SSDT method for over a year and didn't have one. Have a look at the attached files and see if they work for you. E6230_DSDT.zip

If anyone is still having problems with this the brightness function on the arrow keys of my E6230 works fine by patching the BRT6 method in the DSDT. This looks like it should be applicable to most Latitude models as many use the same brightness control method. Open your DSDT source file in MaciASL, click Patch, paste the code below in the top section and click apply.