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

[adrians]

No reinstall required, but I believe you should extract and repatch your DSDT/SSDT files to be on the safe side. You will definitely need to do that if you upgrade your BIOS.

What ig-platfrom-id did you use for the QHD 620?

 

[jkbuha]

With your patches no additional dsdt fixes are required. Usbinjectall.kext is used initially to enable all (working and non) ports but you then remove it once finished.

 

[bozma88]

With your patches no additional dsdt fixes are required. Usbinjectall.kext is used initially to enable all (working and non) ports but you then remove it once finished.

Are you sure about that? By looking at your DSL file, it exposes a UIAC Device (USB-INJECT-ALL?) with a RMCF package (RehabMan-Config?), so my guess is that that SSDT is only a way to configure the behaviour of UsbInjectAll kext. Maybe I am wrong, in that case please point me to the right direction.
A similar structure can be observed in Rehabman CodecCommander SSDT config (which we are using for headphones, by the way).
Please elaborate.

 

[R.MnTnA]

I start to get concerned with the DVMT patch at 96mb on bios 1.2.3. I checked the 899407D7-99FE-43D8-9A21-79EC328CAC21_383 IFR txt file and I couldn't find the option 96mb on the DVMT pre-alloc section:

Setting: DVMT Pre-Allocated, Variable: 0x785 {05 91 0D 05 20 05 35 27 01 00 85 07 14 10 00 FE 00}
0x48DA9 Option: 0M, Value: 0x0 {09 07 0E 05 00 00 00}
0x48DB0 Option: 32M, Value: 0x1 {09 07 0F 05 30 00 01}
0x48DB7 Option: 64M, Value: 0x2 {09 07 10 05 00 00 02}
0x48DBE Option: 4M, Value: 0xF0 {09 07 11 05 00 00 F0}
0x48DC5 Option: 8M, Value: 0xF1 {09 07 12 05 00 00 F1}
0x48DCC Option: 12M, Value: 0xF2 {09 07 13 05 00 00 F2}
0x48DD3 Option: 16M, Value: 0xF3 {09 07 14 05 00 00 F3}
0x48DDA Option: 20M, Value: 0xF4 {09 07 15 05 00 00 F4}
0x48DE1 Option: 24M, Value: 0xF5 {09 07 16 05 00 00 F5}
0x48DE8 Option: 28M, Value: 0xF6 {09 07 17 05 00 00 F6}
0x48DEF Option: 32M/F7, Value: 0xF7 {09 07 18 05 00 00 F7}
0x48DF6 Option: 36M, Value: 0xF8 {09 07 19 05 00 00 F8}
0x48DFD Option: 40M, Value: 0xF9 {09 07 1A 05 00 00 F9}
0x48E04 Option: 44M, Value: 0xFA {09 07 1B 05 00 00 FA}
0x48E0B Option: 48M, Value: 0xFB {09 07 1C 05 00 00 FB}
0x48E12 Option: 52M, Value: 0xFC {09 07 1D 05 00 00 FC}
0x48E19 Option: 56M, Value: 0xFD {09 07 1E 05 00 00 FD}
0x48E20 Option: 60M, Value: 0xFE {09 07 1F 05 00 00 FE}
0x48E27 End of Options {29 02}

Is this because of the bios version?

No it's just not listed for some other reason. This was a concern of mine as well, but it is safe to use 0x3 for 96M. I would upgrade to 1.3.2 first. Then do the DVMT change. Afterwards if you want to confirm it set to 0x3 just type

setup_var 0x785

with nothing after it.

 

[reduxd]

Got DW1560 in the mail today, and swapped it out with the Killer 1535. Wifi works beautifully now, haven't tested Bluetooth or Handoff/AirDrop. For those that swapped the card after installing macOS and don't have wifi showing after the install, you need to invalidate and rebuild the kext caches in order for it to be initialized.

 

[R.MnTnA]

What ig-platfrom-id did you use for the QHD 620?

I've tried both
0x19160004
and
0x19160000
I was only able to change the resolution settings with 0x19160000 with the QHD display, but I'm going to try 0x19160004 with the patch that you posted.

 

[jkbuha]

Are you sure about that? By looking at your DSL file, it exposes a UIAC Device (USB-INJECT-ALL?) with a RMCF package (RehabMan-Config?), so my guess is that that SSDT is only a way to configure the behaviour of UsbInjectAll kext. Maybe I am wrong, in that case please point me to the right direction.
A similar structure can be observed in Rehabman CodecCommander SSDT config (which we are using for headphones, by the way).
Please elaborate.

No need for USBInjectAll.kext once this is correctly implemented. You'll be able to validate this in IOReg by looking at the XHC controller. One condition is to have the correct device-id, which in our case is 9daf. You can check this by reading <device id> for the XHC controller in IOReg.

 

[RehabMan]

@RehabMan, I am aware of that, but since my files use MacBook9,1 there's no truncation, so no need to apply the patch.

Yes, with MacBook9,1, there would be no truncation (it is short enough).
But it seems that people are using other SMBIOS... so if they do that, they need to pay attention and implement the Clover fix for it.

Is there a specific reason for that?
I notice that with OS->Windows brightness keys don't work.

Very little testing has been done with Linux simulation. It all depends on how it affects the EC and ACPI conditional code.
You should be able to make brightness keys work with Windows or Linux. It is must a matter of patching correctly...

 

[RehabMan]

No need for USBInjectAll.kext once this is correctly implemented.

If you're referring to my USB guide, you are misinformed.
The SSDT you create is configuration for USBInjectAll.kext.
If you remove USBInjectAll.kext, the custom SSDT (typically named SSDT-UIAC.aml) has no effect.

 

[RehabMan]

Why?

FixRegions doesn't work reliably. It can actually change the region address when it doesn't need changing...
And you should never need it if your patched/DSDT.aml is in sync with native DSDT.

You would be best off to migrate to ACPI hotpatch, such that you have no patched ACPI files in ACPI/patched (eg. no DSDT.aml)

Why?

The system sets darkwake as needed (via NVRAM) depending on what it is doing...
No need to specify it as zero.
I have never used kernel flag darkwake on any of my hacks.