Contribute
Register
Status
Not open for further replies.
Hi RehabMan,

I don’t know for sure if any of the info I found below (originally posted on ********* within an ALPS touchpad thread) shines any light on things, it’s in relation to getting the brightness keys to remap on a Dell Latitude E6230 (which also has the brightness operated by Fn + Up and Down) but in case I thought I’d post this

“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…

into method label BRT6 replace_content
begin
If (LEqual (Arg0, One))\n
{\n
// Brightness Up\n
Notify (^^LPCB.PS2K, 0x0366)\n
}\n
If (And (Arg0, 0x02))\n
{\n
// Brightness Down\n
Notify (^^LPCB.PS2K, 0x0365)\n
}\n
end;

….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….”


So what I have done is reverted back to my DSDT that has a working SD Card and no issues when running on battery (as my DSDT rebuild wasn’t as good) and I’ve added the above revised BRT6 patch and also deleted the VoodooPS2Controller-R6 kext I was using and installed the kext also mentioned above.

The one thing I haven’t been able to work out is where he says ‘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.’ as whilst I have an additional SSDT-XOSI.aml in relation to OS Check Fix stuff, I’m guessing that isn’t taken care of in that file?

As you have a far superior knowledge than me on this subject does what he says make sense to you?

I’ve attached my debug so hopefully this will highlight was could now be done to hopefully get closer to a solution.

BRT6 method is documented in the guide:
https://www.tonymacx86.com/threads/guide-patching-dsdt-ssdt-for-laptop-backlight-control.152659/
 
Hi RehabMan,

Thank you so much for taking the time out to advise me, really appreciate it but I think for now I will have to leave things as they are until I have a better understanding of ACPI. Whilst I am au fait with low level programming (I did 8 bit Z80 machine code programming back as a kid in the early 80's, which is about as low level as you can get), talking direct to hardware etc and how to apply patches to DSDTs etc, I'm getting a bit lost at the moment with this particular issue. I don't expect someone to hand hold me as ultimately it's down to me to get more up to speed on things, so hopefully I will find where to get guidance on that.

Hopefully I will be able to return to this one day and finally suss out how to remap these key combos without it messing up other things which are currently working really well on my Dell.
 
Hi RehabMan,

Thank you so much for taking the time out to advise me, really appreciate it but I think for now I will have to leave things as they are until I have a better understanding of ACPI. Whilst I am au fait with low level programming (I did 8 bit Z80 machine code programming back as a kid in the early 80's, which is about as low level as you can get), talking direct to hardware etc and how to apply patches to DSDTs etc, I'm getting a bit lost at the moment with this particular issue. I don't expect someone to hand hold me as ultimately it's down to me to get more up to speed on things, so hopefully I will find where to get guidance on that.

Hopefully I will be able to return to this one day and finally suss out how to remap these key combos without it messing up other things which are currently working really well on my Dell.

Since the patch template is provided in the guide, it really isn't that difficult...
 
Since the patch template is provided in the guide, it really isn't that difficult...

Hi RehabMan,

I understand the BRT6 patch stuff in that guide, especially trying it with the various hex codes suggested, indeed as you say that bit is not difficult at all, but I refer to things such as your earlier post (#29) where you mention...

[_Q66].. doesn't exit from there, which means it is taking the early out due to logic related to ECRD:

Code:
            Method (_Q66, 0, NotSerialized)  // _Qxx: EC Query
            {
                \RMDT.P1 ("EC _Q66 enter")
                If (LNotEqual (ECRD, One))
                {
                    Return (Zero)
                }

                NEVT ()
                Return (Zero)
                \RMDT.P1 ("EC _Q66 exit")
            }
So... ECRD must be zero (instead of 1). And as a result, NEVT is never called (which means BRT6 is never called).

ECRD means "EC ready". It is initialized zero, and set to 1 in _REG:
Code:
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
                If (LEqual (LEqual (Arg1, One), LEqual (Arg0, 0x03)))
                {
                    ECIN ()
                    Store (One, ECRD)
                }

                If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03)))
                {
                    Store (Zero, ECRD)
                }
            }
Which means _REG is not getting called (not likely), or ECIN is causing an abort (likely).

You should instrument _REG with ACPIDebug so you can discover what is happening.
After you determine where in the ECIN code path it is failing, you can implement a fix.


It's the lingo like that in italics which I currently don't fully understand how to do because of my limited knowledge of ACPI and as I say I'm not expecting you to literally spell it out for me letter by letter, I'm just grateful you have taken time to point me in the right direction but until the proverbial penny drops for me, some of this remains somewhat confusing.
 
Last edited by a moderator:
...
You should instrument _REG with ACPIDebug so you can discover what is happening.
After you determine where in the ECIN code path it is failing, you can implement a fix.


It's the lingo like that in italics which I currently don't fully understand how to do because of my limited knowledge of ACPI and as I say I'm not expecting you to literally spell it out for me letter by letter, I'm just grateful you have taken time to point me in the right direction but until the proverbial penny drops for me, some of this remains somewhat confusing.

The ACPIDebug patch repo provides a patch for instrumenting _REG.
 
The ACPIDebug patch repo provides a patch for instrumenting _REG.

Ah this is actually a good example of where I end up having trouble finding exactly what I need to find/do, as in this instance if I look at that repo via either the GitHub website or via 'Patches' within MaciASL (having added http://raw.github.com/RehabMan/OS-X-ACPI-Debug/master as a source), I look around there and I see patches with references to things such as Instrument _WAK/_PTS, Instrument EC Queries etc etc but when looking either at the patch list or the contents of the patch files themselves in GitHub I don't see anything obvious to me in relation to instrumenting _REG and as a result I get stuck.

I guess you're probably heavily face palming at the mo reading this and I do feel somewhat stupid and embarrased having to explain why I'm getting stuck in working out exactly where a patch for _REG exists within the repo, but that's sadly where I'm at right now :(
 
Ah this is actually a good example of where I end up having trouble finding exactly what I need to find/do, as in this instance if I look at that repo via either the GitHub website or via 'Patches' within MaciASL (having added http://raw.github.com/RehabMan/OS-X-ACPI-Debug/master as a source), I look around there and I see patches with references to things such as Instrument _WAK/_PTS, Instrument EC Queries etc etc but when looking either at the patch list or the contents of the patch files themselves in GitHub I don't see anything obvious to me in relation to instrumenting _REG and as a result I get stuck.

I guess you're probably heavily face palming at the mo reading this and I do feel somewhat stupid and embarrased having to explain why I'm getting stuck in working out exactly where a patch for _REG exists within the repo, but that's sadly where I'm at right now :(

I thought I had added one for _REG, but I guess not. At any rate, it is easy.

Your _REG method:
Code:
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
                If (LEqual (LEqual (Arg1, One), LEqual (Arg0, 0x03)))
                {
                    ECIN ()
                    Store (One, ECRD)
                }

                If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03)))
                {
                    Store (Zero, ECRD)
                }
            }

Your _REG method with instrumentation:
Code:
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
\rmdt.p1("EC _REG enter")
                If (LEqual (LEqual (Arg1, One), LEqual (Arg0, 0x03)))
                {
\rmdt.p1("EC _REG calling ECIN")
                    ECIN ()
\rmdt.p1("EC _REG returned from ECIN")
                    Store (One, ECRD)
                }

                If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03)))
                {
\rmdt.p1("EC _REG setting ECRD to zero due to Arg1==0,Arg0==3")
                    Store (Zero, ECRD)
                }
\rmdt.p1("EC _REG exit")
            }
 
Last edited:
I thought I had added one for _REG, but I guess not. At any rate, it is easy.

Your _REG method:
Code:
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
                If (LEqual (LEqual (Arg1, One), LEqual (Arg0, 0x03)))
                {
                    ECIN ()
                    Store (One, ECRD)
                }

                If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03)))
                {
                    Store (Zero, ECRD)
                }
            }

Your _REG method with instrumentation:
Code:
            Method (_REG, 2, NotSerialized)  // _REG: Region Availability
            {
\rmdt.p1("EC _REG enter")
                If (LEqual (LEqual (Arg1, One), LEqual (Arg0, 0x03)))
                {
\rmdt.p1("EC _REG calling ECIN")
                    ECIN ()
\rmdt.p1("EC _REG returned from ECIN")
                    Store (One, ECRD)
                }

                If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03)))
                {
\rmdt.p1("EC _REG setting ECRD to zero due to Arg1=0,Arg3=3")
                    Store (Zero, ECRD)
                }
\rmdt.p1("EC _REG exit")
            }

Thank you Rehabman for your patience with me and for further enlightening me in regards to all of this. Reading these lines of code above has now made the penny drop on exactly how ACPIDebug works, it's annoying and embarrassing that I just couldn't grasp the concept before now, I guess that's a caveat of getting older and not being able to digest and process information as well as I used to!

I will report back once I've had some time to instrument _REG etc as I'm determined to get to the bottom of this key remapping spaghetti!

Just a quick one ...would I be right in thinking that the pushed comment in the line :-

\rmdt.p1("EC _REG setting ECRD to zero due to Arg1=0,Arg3=3")

should say

\rmdt.p1("EC _REG setting ECRD to zero due to Arg1=0,Arg0=3")

as it refers to

If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03))) ?
(Guessing that's correct and it was just a minor typo but just wanted to be 100% sure)
 
Just a quick one ...would I be right in thinking that the pushed comment in the line :-

\rmdt.p1("EC _REG setting ECRD to zero due to Arg1=0,Arg3=3")

should say

\rmdt.p1("EC _REG setting ECRD to zero due to Arg1=0,Arg0=3")

as it refers to

If (LAnd (LEqual (Arg1, Zero), LEqual (Arg0, 0x03))) ?
(Guessing that's correct and it was just a minor typo but just wanted to be 100% sure)

Yes. Typo.
 
Hi Rehabman,

I have been trying to press on with using ACPIDebug to trace the brightness keys but seem to have hit a bit of an issue which I hope you might be able to assist with. Basically I’m getting differing results in the log depending on how my Dell boots up.

Randomly, despite not making any known alterations, my Dell will sometimes black screen during the boot sequence (after the logo glitch fix kicks in) and keep black screening every 30-60 seconds after I press the brightness keys to bring the screen back and eventually go to sleep. Other times it will boot fine (and if I remove SSDT-PNLF from patched to stop AppleBacklightInjector from running then I never get the black screen issue but obviously I then can’t look at getting the brightness HUD to work when that’s not running)

I have looked around but haven’t been able to determine a fix for the random black screen issue in relation to AppleBacklightInjector so would you have any ideas why this happens? I know you may well consider that off-topic, but I'm mentioned in this because it seems to have an influence on getting the brightness keys to work (but I'm happy to open a new topic concerning that if you feel it's necessary)

What I also did was to add extra push messages for Method _L13 under _GPE (shown in italics below) because all I was seeing was just ACPIDebug: "GPE _L13 enter" entries for each brightness key press, so that I could see and understand how many commands were getting executed line by line and in the case of :-

A) the laptop boots without the black screen issue
B) does boot with the black screen issue but BEFORE it goes to sleep

I will get these push messages per brightness keystroke :-

ACPIDebug: "GPE _L13 enter"
ACPIDebug: "GPE _L13 Store 0,GPE3"
ACPIDebug: "GPE _L13 Or GL08, 0x10, GL08"
ACPIDebug: "GPE _L13 Notify _SB.PCI0.SAT0, 0x82"
ACPIDebug: "GPE _L13 Return 0 - should that be 'exit'?"


BUT if I try the brightness keys again after waking it up from sleep (and the black screen issue stops as well after waking) then I get a few more push messages showing in the log

ACPIDebug: "GPE _L13 enter"
ACPIDebug: "GPE _L13 Store 0,GPE3"
ACPIDebug: "GPE _L13 Or GL08, 0x10, GL08"
ACPIDebug: "GPE _L13 Notify _SB.PCI0.SAT0, 0x82"
ACPIDebug: "GPE _L13 Return 0 - should that be 'exit'?"

ACPIDebug: "EC _Q66 enter"
ACPIDebug: "Enter NEVT"
ACPIDebug: "NEVT to EV4 0x0800"
ACPIDebug: "Exit NEVT

Which seems to suggest that in this state it gives me more clues as to what to instrument next to trace. Not sure why a sleep/wake would alter the code execution path but I’m guessing that if I could boot up in that ‘state’ rather than how it boots without the black screen issue then it will make life easier to trace the code but I don’t know what would be the cause of the random black screening, so if you have any ideas I would be grateful.
 
Status
Not open for further replies.
Back
Top