Yosemite on Dell M6600...a bit of help

[RehabMan]

Just did what I laid out before, and the Brightness slider still doesn't work.

In ioreg PNLF@0 does show connected to ACPIBacklightPanel, but in console, I have this error. "4/25/15 11:03:48.000 AM kernel[0]: ACPIBacklight: Error in getDeviceControl _DOS"

Download patchmatic: https://bitbucket.org/RehabMan/os-x-maciasl-patchmatic/downloads/RehabMan-patchmatic-2015-0107.zip
Extract the 'patchmatic' binary from the ZIP. Copy it to /usr/bin, such that you have the binary at /usr/bin/patchmatic.

In terminal,

rm -R ~/Downloads/RehabMan
mkdir ~/Downloads/RehabMan
cd ~/Downloads/RehabMan
patchmatic -extract

Post contents of Downloads/RehabMan directory (as ZIP).

Also, post ioreg: http://www.tonymacx86.com/audio/58368-guide-how-make-copy-ioreg.html. Please, use the IORegistryExplorer v2.1 attached to the post! DO NOT reply with an ioreg from any other version of IORegistryExplorer.app.

 

[kapone]

Zip file containing all 3 items.

View attachment Archive1.zip

 

[RehabMan]

Zip file containing all 3 items.

View attachment 135313

Remove ACPIBacklight.kext, rebuild cache, reboot. This will cause your system to use AppleBacklight.kext.

If your backlight slider works with AppleBacklight.kext, then it is a problem with your DSDT being out-of-sync with native DSDT. In that case, re-patch DSDT from fresh native extract.

If your backlight slider does not work with AppleBacklight.kext, then your laptop does not use the IGPU PWM controls for the backlight (it is rare, but some laptops don't use it... such as the Lenovo u310/u410).

If your laptop doesn't use the PWM registers, you can try to use the native OEM methods for brightness. To test, patch with "Brightness Fix" instead of "Brightness Fix (HD3000/HD4000)". You may need to have the DSDT emulate an appropriate version of Windows ("OS Check Fix" patch).

All of this is covered in the two guides previously linked.

 

[kapone]

Just tried it. Without ACPIBacklight.kext, the slider still doesn't work.

Now, I tried the native patch "Brightness Fix" yesterday, and that didn't seem to work either, however, I can't apply the "OS check fix", as it produces 0 changes and the Apply button is greyed out in MaciASL.

Having said that, my goal is not so much the brightness control itself (the Fn + Up Arrow/Down Arrow seem to control the backlight directly at the BIOS/Hardware level). My goal is more Lid Sleep/Wake and battery status, however, my understanding was that, to achieve that, I need to have working screen brightness.

Is that correct?

 

[RehabMan]

.. however, I can't apply the "OS check fix", as it produces 0 changes and the Apply button is greyed out in MaciASL.

Your DSDT is a bit atypical. Sometimes you have to look at the patch to determine its intention, then modify as needed... Look for _OSI and you'll see where it detects Windows version.

Your DSDT supports up to Win7 ("Windows 2009"):

...
                    If (_OSI (WIN7))
                    {
                        Store (0x80, ACOS)
                    }
...

So, if you want it to treat OS X as Win7, change:

                    If (_OSI ("Darwin"))
                    {
                        Store (0x80, ACOS)
                    }

There is also a second check in IINI (interestingly only up to Windows Vista):

...
                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }

You can change:

...
                If (_OSI ("Darwin"))
                {
                    Store (0x07D6, OSYS)
                }

You might check for a BIOS update.

Having said that, my goal is not so much the brightness control itself (the Fn + Up Arrow/Down Arrow seem to control the backlight directly at the BIOS/Hardware level).

That is typical when PWM is not being used...

My goal is more Lid Sleep/Wake and battery status, however, my understanding was that, to achieve that, I need to have working screen brightness.

Battery status is unrelated to brightness. But with even a non-working brightness slider... will enable lid sleep, provided your ACPI LID object is working. There are also patches in my repo related to fixing LID... (eg. removing the _PRW object from it).

 

[kapone]

I think I need to go do something else for a bit...

My brain is hurting from reading the DSDT. I've even installed your ACPI Debug as a last resort to see if I can spot something, and while I can generate debug messages in some places, The "logic" of how the system determines when it's on AC vs BAT is still escaping me.

Any help/pointers you can give would be much appreciated. I know you have the guides....and trust me, I wouldn't be asking if I hadn't already digested the guides and I still couldn't make it work.

 

[RehabMan]

...
My brain is hurting from reading the DSDT. I've even installed your ACPI Debug as a last resort to see if I can spot something, and while I can generate debug messages in some places, The "logic" of how the system determines when it's on AC vs BAT is still escaping me.

It is based on ACPI spec for battery status. _BST returns a status field (index 0 of the returned Package) which indicates charging, discharging. If _BST indicates discharging, the system is running on battery. If it doesn't (eg. charging, or not discharging [100% charged]), then the system is running on AC.

Have you got the battery method working yet? It is easy to tell from ioreg... and system.log.

 

[kapone]

Nope. I can't figure out why it's not detecting a battery, when there's one present. Once I get that figured out, I'll move to the next step.

I did confirm that BAT0 is the one that "should" be detected, but it's not. I modified the _STA methods for BAT1 and BAT2 to return 0.

 

[RehabMan]

Nope. I can't figure out why it's not detecting a battery, when there's one present. Once I get that figured out, I'll move to the next step.

Check system.log. ACPIBatteryManager.kext will tell you if a method is failing.

 

[kapone]

Have you got the battery method working yet? It is easy to tell from ioreg... and system.log.

Still failing at:

4/25/15 5:20:58.000 PM kernel[0]: AppleSmartBatteryManager::getBatterySTA: evaluateObject error 0xe00002bc