Contribute
Register

[Guide] Dell XPS 13 9360 on MacOS Sierra 10.12.x - LTS (Long-Term Support) Guide

Status
Not open for further replies.
Hello,

Rehabman's steps fixed it - I can plug in and unplug and it works seamlessly. I will try to check whether it was _SB.EC or FakePCIID_Intel_HDMI_Audio.kext that did it.

Thanks again to both of you

PS I am running BIOS 1.3.5, having upgraded from 1.3.2 just before switching to the beta hotpatch files.

Please, check whether HDMI/DP audio still works with that kext installed.
In my case, adding Intel_HDMI_Audio.kext disables HDMI audio, so it's a no-go.
Thank you.
 
Last edited:
Some minor issues:

- Battery menu icon doesn't appear in red colour when is <10%
- Wifi signal menu icon of current connected network is always at 100%
- Shift + insert reboots the computer instead of sleeping it
- Brightness levels aren't restoring after reboot
- Couldn't map alt (option) to caps lock, because it messes up with the toggle function

1) Mine works
2) Never seen this happen. Check RSSI levels by clicking icon with ALT pressed
3) Shift+ins is not mapped to power dialog, how did you manage to do this?
4) Correct. It needs a Mac plist with brightness sensor and ALS0 device implemented
5) I don't understand why you would map alt to caps lock.........................
 
I had the same problem when I plugged a USB-C to HDMI cable in. Haven't really spent time debugging this as it wasn't a priority - what I did try was increasing the DVMT memory allocation but to no avail.

I ordered a miniDP adaptor but a DP turned up from China, am waiting for the replacement to turn up in the next few weeks(months?)

If I remember correctly, you are using a different audio kext (not Clover HDA). This may be the cause of your reboots.
I confirm HDMI audio working and no reboots with my beta config and USB-C => HDMI converters or direct cables.
 
Verify your assumption by implementing "IRQ Fix" (static patch).

Note: Normal behavior of the power button in macOS is that pressing it a short time does nothing. Longer will sleep. On real Macs, must press Ctrl at the same time to get power dialog.

Another (small) improvement.

@RehabMan, @jkbuha, @skydrops, @landmarker, I found the cause of PBTN not working.
On my original guide, _OSI was set to Linux, in the hotpatching config it's set to Windows.
Reverting to Linux restores correct behaviour of Power Button.

With _OSI to Windows:
=> Short press: nothing (correct)
=> Long press: nothing (not correct)

With _OSI to Linux:
=> Short press: nothing (correct)
=> Long press: Sleep (correct)*

This also makes possible (again) to wake the screen by pressing the power button.
With _OSI = Windows, when the screen shut down, you had to press a key or trackpad to turn it on.
The low-level reason should be investigated.

I have to ask you 9360 owners to test this:
A) Stay with the hot-patching assets, do not change nor implement anything else.
B) Revert to OSI = Linux**, and tell me:
1) if the power plug freeze starts occurring again,
2) if Power button now works with long press,
3) if you notice other issues directly related to this change.


Notes:
* In addition to that, if you want the power dialog to appear after a long press instead of sleep, type in console:
Code:
defaults write com.apple.loginwindow PowerButtonSleepsSystem -bool no
** To revert to OSI = Linux, swap SSDT-XOSI.aml with the one attached to this post.
 

Attachments

  • SSDT-XOSI.aml
    66 bytes · Views: 127
Last edited:
Another (small) improvement.

@RehabMan, @jkbuha, @skydrops, @landmarker, I found the cause of PBTN not working.
On my original guide, _OSI was set to Linux, in the hotpatching config it's set to Windows.
Reverting to Linux restores correct behaviour of Power Button.

With _OSI to Windows:
=> Short press: nothing (correct)
=> Long press: nothing (not correct)

With _OSI to Linux:
=> Short press: nothing (correct)
=> Long press: Sleep (correct)*

This also makes possible (again) to wake the screen by pressing the power button.
With _OSI = Windows, when the screen shut down, you had to press a key or trackpad to turn it on.
The low-level reason should be investigated.

I have to ask you 9360 owners to test this:
A) Stay with the hot-patching assets, do not change nor implement anything else.
B) Revert to OSI = Linux**, and tell me:
1) if the power plug freeze starts occurring again,
2) if Power button now works with long press,
3) if you notice other issues directly related to this change.


Notes:
* In addition to that, if you want the power dialog to appear after a long press instead of sleep, type in console:
Code:
defaults write com.apple.loginwindow PowerButtonSleepsSystem -bool no
** To revert to OSI = Linux, swap SSDT-XOSI.aml with the one attached to this post.

You might want to analyze DSDT code to determine what conditional code (having to do with _OSI) is affecting the power button specifically.

Especially if switching to Linux simulation causes other issues.
 
Please, check whether HDMI/DP audio still works with that kext installed.
In my case, adding Intel_HDMI_Audio.kext disables HDMI audio, so it's a no-go.
Thank you.

Note that the device-id that FakePCIID_Intel_HDMI_Audio.kext spoofs is configurable via RM,device-id injection.
Different computers require different values.
It is a process of trial/error.
 
I have to ask you 9360 owners to test this:
A) Stay with the hot-patching assets, do not change nor implement anything else.
B) Revert to OSI = Linux**, and tell me:
1) if the power plug freeze starts occurring again,
2) if Power button now works with long press,
3) if you notice other issues directly related to this change.

Well the good news is that we now know the root cause of the power plug freeze.
Reverting to OSI = Linux brings back the power plug freeze...
 
Well the good news is that we now know the root cause of the power plug freeze.
Reverting to OSI = Linux brings back the power plug freeze...

Good catch.
Can you help me determine the ACPI code related to OSI change that makes the Power Button work?
I don't see any obvious relations.
 
Good catch.
Can you help me determine the ACPI code related to OSI change that makes the Power Button work?
I don't see any obvious relations.

Might be worth comparing PBTN, XOSI and OSYS declarations to begin with. Here's my Vanilla DSDT - let's do a diff on it with yours...
 

Attachments

  • System DSDT.dsl
    1.1 MB · Views: 140
Might be worth comparing PBTN, XOSI and OSYS declarations to begin with. Here's my Vanilla DSDT - let's do a diff on it with yours...

Here are the conditions triggered if XOSI = Linux

Code:
            Method (_INI, 0, NotSerialized)  // _INI: Initialize
         
                If (LLess (OSYS, 0x07DC))
                {
                    SRXO (GPDI, One)
                }

...
            Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
            
                If (LLess (OSYS, 0x07DC))
                {
                    Return (SBFI)
                }

...
             If (XOSI (LINX))
                    {
                        Store (0x40, ACOS)
                    }
 
Last edited:
Status
Not open for further replies.
Back
Top