Amoxitine

Hi @jpz4085,haven't had much time so far to do a full instrumentation , but I do recall that I had previously downloaded the ioio utility, so I ran that and from the console I get these entries when I press the OSX brightness keys :- Fn + F3 = ApplePS2Keyboard: sending key 46=6b down Fn + Insert = ApplePS2Keyboard: sending key e045=71 down If I press Fn + Down or Fn + Up I don't get anything, but not sure if I should get anything back or not (guessing that perhaps not?). Would I be correct in thinking that I will definately need to use full instrumentation because the hardware brightness keys aren't passing anything through PS2 key codes?

Hi @jpz4085, that's interesting what you said about the GPE _L13 method is only SATA related as the timestamps for those entries did appear to coincide with pressing the brightness keys, but they may be coincidental. I managed to try out patching _INI and OSID with both Win 2009/7 and Win 2012/8 (the latter didn't have an entry for that by default so had to search for the correct Store value (Store (0x07DC, OSYS) ) under _INI to implement that, but it doesn't seem to make any difference (assuming you mean that when these Darwin patches are correct, that Fn + F3 and Insert stop working and just leaves Fn + Up & Down control sans HUD, which isn't the case?). I'm guessing that until I resolve that issue that there's no benefit in instrumenting the method calls? If so would you have any other ideas as to how to get the proper version of Windows simulated? Attached is latest debug in case I may have messed up on the Darwin patches (I did notice an existing extra entry under _OSC for Windows 2012 but left that alone as wasn't sure if that was connected or not to the brightness keys) debug_29369.zip

Hi @jpz4085 as ever thank you for your efforts here. I’ve spent the last couple of hours or so testing the DSDTs you have provided and to summarise where I’m at here’s a rundown of what occurred… 1) Through my tests I have now discovered that irrespective of the DSDT used (my original or yours), the sleep / brightness issue occurs when there is a discrepancy between the brightness level set by the default Dell brightness keys (Fn + UP & DOWN) and the OSX brightness control keys (Fn + Insert & F3), in that if the Dell brightness level is higher than the OSX HUD version it seems to induce that issue upon reboot, but if I then set both of them to maximum and reboot again, then the issue goes away and as long as I adjust the levels with just the OSX assigned keys and not the Dell ones, it seems to keep that issue at bay. 2) I reinstated ACPIDebug kext to /L/E, flushed the cache and rebooted with your Debug DSDT initially but nothing ACPIDebug related was showing in the log when I did some brightness key strokes, so I added the Instrument GPE Events patch to that Debug DSDT and then I was getting lots of ACPIDebug: "GPE _L13 enter" entries appear in the log for when I was pressing the Dell key combos keys but no other ACPIDebug entries I could see apart from that (and got the same if I pressed the OSX assigned key combos), so I’m assuming there is a more convoluted path these key presses are taking that will need further debugging? I’ve done a new debug from that point so hopefully something may become apparent! debug_10041.zip

Hi @jpz4085, I went through all of the steps you kindly outlined above, but even if I make the additional changes to the Darwin patches and the value of darkwake to 'no', sadly it will still start blacking out the display just after midway of the boot sequence (when the brightness fix flash occurs) and continues that way until it goes to sleep by itself and I wake it. Just to let you know that in that pre unstable state the brightness slider is showing in prefs but moving it has no effect, the only control is via the original hardware mapped key combos (Fn + up and down) sans the HUD. Out of curiosity having made your additional changes to config.plist and removing/restoring the kexts you mentioned, if I just swap back my latest 'working' DSDT in place of your DSDT into the patched folder then the brightness/sleep issue doesn't occur at all. If it helps what I've done is a new debug from just after I made all your suggested changes, plus uploaded this 'no brightness/sleep issue' DSDT in case it may offer clues as to why the other DSDT is still generating the brightness/sleep issue. My Latest DSDT.aml.zip debug_18858.zip

Hi @jpz4085, Thank you so much for taking the time out to take a look at my config, wasn't expecting that so I'm very grateful. I have tried your updates, but unfortunately it's now behaving like this... 1) Constantly going into sleep state after 20-30 seconds where I have to either keep pressing Fn + Up, then Fn + Insert, then Fn + Up quickly each time the display goes to black to wake it up. 2) Fn + F3 and Fn + Insert no longer control brightness (but still shows the HUD, only Fn + Up and Down only control the brightness without the HUD). If I let it go into a sleep state and then wake it up, which takes about 30-60 seconds to wake (or reboot if it doesn't wake) then the repetitive sleep issue goes away and behaves more like it should (plus it returns brightness control back to Fn + F3 and Insert) until I reboot again and then it comes back. I don't know whether this might be to do with me reverting back to using the VoodooPS2Controller-R6.kext since I did my last debug that you looked at (as I found this had better mapping for the Dell's keyboard compared to another Voodoo kext I found that works with my Alps V3 touchpad) and then applying your updates after that? Not sure if it helps but I did do another debug which is my most stable config to date called debug_no_sleep_issue (which was just prior to applying your updates) which I think might be a touch different to the one you looked at (but I could be wrong) plus a debug of how things are at the mo. If you have any further suggestions etc I would be very grateful debug_no_sleep_issue.zip debug_latest_with_updates.zip

Hi Hervé, Yeah I've already been trying to use Rehabman's ACPIDebug to establish the codes, but I can't get much further than establishing the start point (_Q66) in the chain but it doesn't reach BRT6 so when I saw jpz4085's post about needing to apply the OS Check Fix to the appropriate _OSI checks I was thinking that perhaps that's the reason why I can't establish the key codes in the sys log, but with my limited knowledge that's where I've got stuck. No worries if you can't advise any further, just thought I'd ask in case you might be able to nudge me in the right direction.

Hi @Hervé and @jpz4085, I was hoping one of may help me in regards to getting my brightness keys mapped properly on my Dell E5430. I see that jpz4085 recently posted the following.... "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." Would one of you perhaps be so kind as to take a look at my debug and see what else I would need to do, as I've already applied the BRT6 patch to my DSDT and have a OS Check Fix in place via an additional SSDT in my patched folder but I'm guessing that it doesn't extend to Method _INI etc mentioned above. I'm also using the same VoodooPS2Controller kext that jpz4085 included in his zip file (as I was previously using the R6 version) - I've had to do some other key remapping via Karabiner-Elements when using this kext but it would be nice to have the Fn + Up / Down keys to solely control brightness with the HUD showing, rather than having two versions of brightness control (Fn + F3 and Fn + Insert with the HUD and Fn + Up / Down without the HUD). Any advice would be appreciated as I'm struggling to nail this final piece of the jigsaw. debug_14446.zip

New development - Not entirely sure why, but by turning on the legacy boot option in the BIOS so that I could boot off the DVD drive seems to have activated the Fn + Cursor Up / Down brightness control keys when Sierra has booted, albeit it doesn't show the brightness graphic (but Fn + F3 and Fn + Insert still work and show the graphic bar), so it's like I now have two brightness controls that are independent of each other. Still haven't been able to generate the key codes, but thought I should mention this and whether it is still possible get the Fn + Cursor Up / Down to show the brightness graphic (even though I still can't get key codes to appear in system.log)?

Thanks guys for the heads up on the patch to fix the compiler error, that's sorted that problem. For some reason I just can't get the key codes to show in system.log when I press the various combinations, despite patching my DSDT with.... Add DSDT Debug Method Instrument EC Queries Instrument GPE Events and Kext Wizard showing that ACPIDebug is installed (to /S/L/E), as well as swapping out VoodooPS2Controller-R6.kext with one of RehabMan's VoodooPS2Controller.kext (which also works with my trackpad) Can't work out what I might have missed so as always if any of you have any advice to get it to fire out the key codes I would be grateful. I have attached my latest DSDT as a DSL (apologies Herve didn't know it needed to be a DSL - never stop learning!) plus the two Voodoo kexts I have tried alongside the debug. Cheers, Voodoos.zip DSDT_amox.dsl.zip

Hi Bronxteck, Funny enough I did come across Karabiner and installed it but whilst it enables me to remap brightness control to F1 (darken) and F2 (lighten), it doesn't seem to allow me to create the remaps to Fn + Down and Fn + Up, which ideally I would prefer. I have been doing more reading up on the subject and have been looking to add RehabMan's ACPIdebug patch to my patched DSDT.aml that was patched by Jake Lo earlier in this thread so that I can work out the key codes for the two key combinations via syslog but I can't re-compile it using Rehabman's latest version of MaciASL (RM - 1.31 (252.4)) as I get the following errors... 2436, 6126, syntax error, unexpected PARSEOP_IF, expecting PARSEOP_CLOSE_PAREN or ',' 2440, 6126, syntax error, unexpected PARSEOP_CLOSE_PAREN 4698, 6126, syntax error, unexpected PARSEOP_SCOPE, expecting $end and premature End-Of-File This is irrespective if I apply any new patches and re-compile or just re-compile the DSDT immediately after opening it. Jake, if you read this (or anyone else), would you have any ideas as to why I'm getting these errors with the DSDT you patched for me the other day? I've attached it below for you to take a look at. Cheers, Dave DSDT.aml.zip

Hi Hervé, Thanks for your reply. Yes the keys work as intended outside of OSX, so will have to do as you say. I will have a search around t'interweb to see if I can find the guide you mentioned, but if anyone else reading this has any pointers I would be grateful Cheers,

Hi Bronxteck, Well after a long drawn out struggle I have managed to get the backlight working via booting with AptioMemoryFix-64.efi and adding the necessary updates to config.plist to get the AppleBacklightInjector.kext loading and working (following RehabMan's instructions elsewhere). Just one final niggly issue which I hope either yourself or Jake might be able to point me in the right direction....it appears the brightness controls are mapped to Fn + F3 (bright down) and Fn - Insert (bright up) keys instead of Fn + Cursor Down key and Fn + Cursor Up key. Is there a way to remap those keys to the correct one in a 'fairly simple to understand for a noob' way? Cheers,

Hi Bronxteck, Cheers for your reply, I was using an older version (1.0.0) of the BCM5772D ethernet kext in /S/L/E so I upgraded to v2.3.6 and after a few kernel panics it's working better, but still there are times on boot up it won't have a properly assigned MAC address so I then have to reboot again once or twice more to get it to appear. Not sure why it's working intermittenly like that still despite updating the kext (and I've flushed the kextcache via Kext Utility), if you have any ideas why I'd be grateful, but at least when it works, it works fine! Still would like to get backlight controls working, but all my efforts to do so just seem to hit brick walls

Hi Jake, Further to my last post I have somehow managed to get the Del working at full speed and pretty much have everything working now, but just have two issues that it would be handy to fix if possible. 1) I don't seem to be able to get the backlight brightness control working despite trying a few different things (either doesn't add any control or will cause boot failure) 2) Ethernet is still flaky (when it's not working it will show MAC address as 00 etc, either multiple reboots or deleting NetworkInterfaces.plist from /Library/Preferences/SystemConfiguration and rebooting will get it to work) If you could take a glance at my latest debug and see if there's anything that can be tweaked to fix either / both issues I would be grateful. Cheers, debug_6986.zip

Hi Jake, I redid everything from your first post again just to see if that would get things right, but unfortunately I'm still having issues. The only way to get it to boot is to untick Drop "SSDT" Cpu0Ist" 2489 and Drop all OEM SSDT (leaving either or both ticked will generate the error in my screen shot above) and either leaving Drop "SSDT" "CpuPm" 2850 either ticked or unticked under drop tables on startup (that one doesn't seem to make any difference), but as before whilst I seem to have access to everything (now including brightness control) it's running so much slower that it has been. Any ideas how I could speed it up? Done another debug for you to see if that might highlight something that needs altering. Cheers, debug_4064.zip