Refined ALPS TouchPad driver

[Hervé]

@Amoxitine, I'd go back to your initial settings and discuss with @jpz4085 the DSDT debugging patches you need to apply in order to identify the codes associated to your Fn-UP/Fn-DOWN keystrokes.

[Amoxitine]

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

[jpz4085]

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

[Amoxitine]

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

[jpz4085]

This is useful to know and actually sounds familiar; I think I had seen that at one point when debugging my DSDT originally.

 

On 9/27/2018 at 6:25 PM, Amoxitine said:

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?

 

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.

[Amoxitine]

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

[jpz4085]

15 hours ago, Amoxitine said:

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.

 

As far as I can tell by looking at the code in GPE _L13. Maybe something else is going on.

 

15 hours ago, Amoxitine said:

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

 

All the Darwin patches look good and you're right there was none for WIN8 under _INI so that one might not matter. 

 

15 hours ago, Amoxitine said:

that Fn + F3 and Insert stop working and just leaves Fn + Up & Down control sans HUD, which isn't the case?).

 

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.

 

16 hours ago, Amoxitine said:

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?

 

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.

[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?
 

 

 

[jpz4085]

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.

[biscate]

Hi guys,

 

I've been experienced an issue with VoodooPS2Controller-R6B10fixed.kext on Mojave.

 

The cursor movement stops after sleep and/or screen saver.

 

Tried other releases from here, but no one else works on my machine.

 

This kext works well on High Sierra.

 

Thanks.