Contribute
Register

El Capitan Beta with Dell XPS 13 9343 (Early 2015 Model)

Status
Not open for further replies.
RehabMan said:
The idea is to determine by tracing with ACPIDebug what status you can read from the EC to disambiguate calls to _Q66.
Click to expand...

Maybe I misunderstand but I feel like I have done that to a point. I found that when the keys are pressed they go Q66 - EV4 - WMNF - SWEV. But at SWEV I feel like it's a dead end:

Method (SWEV, 1, NotSerialized)
{
Or (WMEV, Arg0, WMEV) /* \_SB_.AMW0.WMEV */
}
 
dudenesspa said:
Maybe I misunderstand but I feel like I have done that to a point. I found that when the keys are pressed they go Q66 - EV4 - WMNF - SWEV. But at SWEV I feel like it's a dead end:

Method (SWEV, 1, NotSerialized)
{
Or (WMEV, Arg0, WMEV) /* \_SB_.AMW0.WMEV */
}
Click to expand...

Post instrumented DSDT and related ACPIDebug output clearly correlated with each keypress.
 
RehabMan said:
Post instrumented DSDT and related ACPIDebug output clearly correlated with each keypress.
Click to expand...

Thanks for the help Rehabman! Here are the files.
 

Attachments

  • DSDT.aml
    79.8 KB · Views: 94
  • acpidebug.txt
    1.5 KB · Views: 85
RehabMan said:
You need to more fully instrument NEVT so you know which code path it is following.
Click to expand...

OK so I instrumented some more and now I've found another path that goes to ECR2 and ECR1. Not sure what to do next. Am I getting warm?
 

Attachments

  • DSDT.aml
    80.7 KB · Views: 80
  • acpidebug.txt
    3.3 KB · Views: 70
dudenesspa said:
OK so I instrumented some more and now I've found another path that goes to ECR2 and ECR1. Not sure what to do next. Am I getting warm?
Click to expand...

Since you know Local0 in NEVT (result of ECG1 call) is 0x800, you know it follows this path:
Code: 
        If (And (Local0, 0x0800))
        {
            EV4 (0x0800, Zero)
        }

Which eventually results in a call to WMNF:
Code: 
        Method (WMNF, 2, NotSerialized)
        {
            \RMDT.P1 ("WMNF enter")
            \_SB.AMW0.SWEV (Arg0)
            Notify (\_SB.AMW0, 0xD0)
            \RMDT.P1 ("WMNF exit")
        }

Which results in a Notify to the AMW0 device. It is at this point the OEM backlight driver would get control and call additional methods in DSDT (likely inside AMW0).

I think part of your problem is your DSDT is not correctly patched to deal with _OSI("Darwin").

Note the OSID method is completely not patched:
Code: 
        Method (OSID, 0, NotSerialized)
        {
            If (LEqual (ACOS, Zero))
            {
                Store (One, ACOS)
                Store (Zero, ACSE)
                If (CondRefOf (\_OSI, Local0))
                {
                    If (_OSI (WXP))
                    {
                        Store (0x10, ACOS)
                    }

                    If (_OSI (WLG))
                    {
                        Store (0x20, ACOS)
                    }

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

                    If (_OSI (WIN8))
                    {
                        Store (0x80, ACOS)
                        Store (One, ACSE)
                    }

                    If (_OSI (WN81))
                    {
                        Store (0x80, ACOS)
                        Store (0x02, ACSE)
                    }

                    If (_OSI (LINX))
                    {
                        Store (0x40, ACOS)
                    }
                }
                ElseIf (STRE (_OS, W98S))
                {
                    Store (0x02, ACOS)
                }
            }

            Return (ACOS)
        }

Try with:
Code: 
        Method (OSID, 0, NotSerialized)
        {
            If (LEqual (ACOS, Zero))
            {
                Store (One, ACOS)
                Store (Zero, ACSE)
                If (CondRefOf (\_OSI, Local0))
                {
                    If (_OSI (WXP))
                    {
                        Store (0x10, ACOS)
                    }

                    If (_OSI (WLG))
                    {
                        Store (0x20, ACOS)
                    }

                    [B]If (LOr(_OSI("Darwin"), _OSI (WIN7)))[/B]
                    {
                        Store (0x80, ACOS)
                    }

                    If (_OSI (WIN8))
                    {
                        Store (0x80, ACOS)
                        Store (One, ACSE)
                    }

                    If (_OSI (WN81))
                    {
                        Store (0x80, ACOS)
                        Store (0x02, ACSE)
                    }

                    If (_OSI (LINX))
                    {
                        Store (0x40, ACOS)
                    }
                }
                ElseIf (STRE (_OS, W98S))
                {
                    Store (0x02, ACOS)
                }
            }

            Return (ACOS)
        }

The OSID method is used extensively in your DSDT so it is important to have it emulate a version of Windows when running "Darwin".

There is a few other (unpatched) checks of _OSI that you may wish to review.
 
I do not know why people here don't lay out what they do better than what they do... but any ways after doing the following I pulled the Ambient Light sensor data to set it via the efi shell.

Had to install Windows 10 and wipe out my OSX install because of this one thing...

1. Download the "Universal BIOS Backup ToolKit 2.0.exe" it is the only thing that will dump the Dell BIOS.
2. Run it, read it, save it.
3. Get the latest "UEFITool.exe" and open the rom file you just dumped and find the "search" option in the top menu and just look for "SetupPrep" that way... you will never find it searching manually. Now extract the PE32 image of the module.
4. You will now have a .bin file and you will use "Universal IFR Extractor.exe" to convert it to be human readable.
5. Profit???

All in all the process is simple... but it takes a lot of head scratching still because no one has clearly laid it all out in one freaking post for this laptop.

Sad thing is I have only seen like 2 people that have posted and clearly done anything similar and neither one of them slowed down to think that maybe we can ALSO turn off the annoying Ambient Light sensor that keeps changing our brightness on us!!!

Here is it, boot into the EFI Shell using one of the larger bootx64.efi files (over 2mb) and the type this "setup_var 0xe6 0x0".

That's it... you're done.

For me personally my brightness keys are still broken in El Capitan, but the slider does work and I can resolve this later. The auto brightness though was really killing my eyes and giving me headaches.
 
Ok, I need some help.

Computer Specs:
- 5200U
- UHD Display
- 8GB Ram
- 256GB SSD
- BCM94352 wifi/bt

EFI & IOREG:
View attachment xps13ioreg_12-26-15.ioreg
View attachment CLOVER.zip

Issues:
- Wifi is enabled through fakepci but wont turn on (symbol shows up but can't enable radio through either the bar or terminal).
- Randomly dimming screen (I think that someone above said that this needs dsdt edits)
- Bluetooth should be enabled but doesnt show up even in system profiler
 
irocktolive7 said:
Ok, I need some help.

Computer Specs:
- 5200U
- UHD Display
- 8GB Ram
- 256GB SSD
- BCM94352 wifi/bt

EFI & IOREG:
View attachment 169143
View attachment 169144

Issues:
- Wifi is enabled through fakepci but wont turn on (symbol shows up but can't enable radio through either the bar or terminal).
- Randomly dimming screen (I think that someone above said that this needs dsdt edits)
- Bluetooth should be enabled but doesnt show up even in system profiler
Click to expand...

http://www.tonymacx86.com/el-capitan-laptop-support/173616-guide-10-11-usb-changes-solutions.html

http://www.tonymacx86.com/el-capitan-laptop-support/152573-guide-patching-laptop-dsdt-ssdts.html
 
Status
Not open for further replies.
Copyright © 2010 - 2024 tonymacx86 LLC
Back
Top