Jump to content

[GUIDE] Dell XPS 15 (9550) Mojave 10.14 / 10.15 Quick Installation


Krim404
 Share

1,806 posts in this topic

Recommended Posts

FYI, unsigned kext messages are normal.  It's a hackintosh it's going to have non-official kexts loading.

 

 

I’m on 10.13.3 now. I still can get my brightness controls to work.
Even after rebuilding the kernel caches.

I’m getting some complains about invalid signatures what appears to say it was allowed.

I did the commands from the guide to flush the kernel cache.
Any ideas on how to fix?

 

 

EDIT: I have  no idea what i've done. After a few flushes, the brightness control is working  again. I tried to allow unsigned code again through that spctl command. And after the last flush it seems to have fixed it. I'm not really sure.

 

Are there any advantages in going to the new Clover, also the github repo seems to have been updated with a few new things, something about nvram and aptio v3..... should i move to those?

Link to comment
Share on other sites

  • 3 weeks later...

Hi Folks, seeking your advice if you will?

 

System: 9550, i7, 16gb, 4k screen, Toshiba SSD.   Install as per the GitHub repo, switching the SSD to 4k sectors, and following up with a Win10 dual-boot for games, though most of my work will be in OSX.

 

Audio - I left it 'as is', everything is fine through speakers, but I get corruption when using headphones plugged into the laptop (as expected).   None of the other options seemed particularly enticing (would rather audio disruption than kernel panics), but thought 'never mind, I'll use Bluetooth headphones'.

 

Having acquired a serviceable pair, which work perfectly with my phone, I think evening paired them with the laptop.  However, the end result isn't great (wired with corrpution is better).   They regularly (between 2 and 5 mins) disconnect, and when connected, more often than not, the sound is garbled.  When is is playing properly, it sounds great.

 

Any tips on what I should change?  System stability is priority number one, but after that, bluetooth audio trumps speaker audio if it's a trade off.

 

Many thanks.

 

Gavin.

Link to comment
Share on other sites

Hmm, they're fine on my phone and, having checked, in Win10 on the same machine, so seems to be specific to the headphone/OSX combination.

Anything I should try? or SOL?  I can't pick up a £300 pair of headphones on the off-chance it'll work ;-)

Link to comment
Share on other sites

Solved my issue:  It seems that, when connecting to a 2.4Ghz Wifi connection in OSX (not in Windows 10), my audio gets corrupted.  As soon as I switched over to a 5Ghz connection, everything was absolutely fine, so, I guess something in the card/driver is conflicting with itself.

Link to comment
Share on other sites

its not a conflict... this is normal behaviour with some bt hardware...

wifi and bt are interfering with each other. both are using 2,4ghz for transmission. it depends on quality of your used devices (router, headphones,...) and their transmission settings if the interference will be a mild side effect or a absolute non working disaster.

Link to comment
Share on other sites

  • 2 weeks later...

So, my post was deleted due to the forum's recent changes...

Anyway, here is what you need to enable VoodooI2C on our machine (Better touchpad and touchscreen)

More info about VoodooI2C here (thanks @alexandred for the great work)

Add these two entries to Clover's config.plist at `ACPI > DSDT > Patches`:

<dict>
	<key>Comment</key>
	<string>change GPI0 device _STA to XSTA</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X1NUQQCgCZNTQlJHAA==</data>
	<key>Replace</key>
	<data>WFNUQQCgCZNTQlJHAA==</data>
</dict>
<dict>
	<key>Comment</key>
	<string>change I2C devices _CRS to XCRS</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X0NSUwCgDg==</data>
	<key>Replace</key>
	<data>WENSUwCgDg==</data>
</dict>

Copy the SSDT-I2CX.aml and SSDT-XOSI.aml(thanks @goodwin_c) files inside the attached zip to `CLOVER > ACPI > patched`

Download the latest VoodooI2C.kext release (link) and copy both VoodooI2C.kext and VoodooI2CHID.kext files to Clover's kexts folder . The other files are not needed. (more info about them here)

Reboot and that's it.

Personally I think the performance of our's laptop touchpad is better using VoodooI2C.kext than with VoodooPS2Controller.kext. And the added gestures to the Touchscreen are a nice bonus.

P.S: Don't delete VoodooPS2Controller.kext, as it is still necessary for the keyboard to function and it is compatible with VoodooI2C.

P.S.S: Inside the attached zip I included a beta version of VoodooI2C.kext (10.13 only, based on this changes) that enable native gestures and settings for our touchpad (Just like Apple's Magic Trackpad). However this version is in current development and those willing to test should expect bugs. (Removed per author's request, if you want to know more about this version go here)

 

I2C.zip

Edited by hvolkoff
Changed attachment, removed VoodooI2C beta binary and added missing SSDT-XOSI.aml file
Link to comment
Share on other sites

15 hours ago, hvolkoff said:

So, my post was deleted due to the forum's recent changes...

Anyway, here is what you need to enable VoodooI2C on our machine (Better touchpad and touchscreen)

More info about VoodooI2C here (thanks @alexandred for the great work)

Add these two entries to Clover's config.plist at `ACPI > DSDT > Patches`:


<dict>
	<key>Comment</key>
	<string>change GPI0 device _STA to XSTA</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X1NUQQCgCZNTQlJHAA==</data>
	<key>Replace</key>
	<data>WFNUQQCgCZNTQlJHAA==</data>
</dict>
<dict>
	<key>Comment</key>
	<string>change I2C devices _CRS to XCRS</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X0NSUwCgDg==</data>
	<key>Replace</key>
	<data>WENSUwCgDg==</data>
</dict>

Copy the SSDT-I2CX.aml file inside the attached zip to `CLOVER > ACPI > patched`

Download the latest VoodooI2C.kext release (link) and copy both VoodooI2C.kext and VoodooI2CHID.kext files to Clover's kexts folder . The other files are not needed. (more info about them here)

Reboot and that's it.

Personally I think the performance of our's laptop touchpad is better using VoodooI2C.kext than with VoodooPS2Controller.kext. And the added gestures to the Touchscreen are a nice bonus.

P.S: Don't delete VoodooPS2Controller.kext, as it is still necessary for the keyboard to function and it is compatible with VoodooI2C.

P.S.S: Inside the attached zip I included a beta version of VoodooI2C.kext (10.13 only, based on this changes) that enable native gestures and settings for our touchpad (Just like Apple's Magic Trackpad). However this version is in current development and those willing to test should expect bugs. 

I2C.zip

Could you share your IOReg with VoodooI2C working?

Link to comment
Share on other sites

19 hours ago, hvolkoff said:

So, my post was deleted due to the forum's recent changes...

Anyway, here is what you need to enable VoodooI2C on our machine (Better touchpad and touchscreen)

More info about VoodooI2C here (thanks @alexandred for the great work)

Add these two entries to Clover's config.plist at `ACPI > DSDT > Patches`:


<dict>
	<key>Comment</key>
	<string>change GPI0 device _STA to XSTA</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X1NUQQCgCZNTQlJHAA==</data>
	<key>Replace</key>
	<data>WFNUQQCgCZNTQlJHAA==</data>
</dict>
<dict>
	<key>Comment</key>
	<string>change I2C devices _CRS to XCRS</string>
	<key>Disabled</key>
	<false/>
	<key>Find</key>
	<data>X0NSUwCgDg==</data>
	<key>Replace</key>
	<data>WENSUwCgDg==</data>
</dict>

Copy the SSDT-I2CX.aml file inside the attached zip to `CLOVER > ACPI > patched`

Download the latest VoodooI2C.kext release (link) and copy both VoodooI2C.kext and VoodooI2CHID.kext files to Clover's kexts folder . The other files are not needed. (more info about them here)

Reboot and that's it.

Personally I think the performance of our's laptop touchpad is better using VoodooI2C.kext than with VoodooPS2Controller.kext. And the added gestures to the Touchscreen are a nice bonus.

P.S: Don't delete VoodooPS2Controller.kext, as it is still necessary for the keyboard to function and it is compatible with VoodooI2C.

P.S.S: Inside the attached zip I included a beta version of VoodooI2C.kext (10.13 only, based on this changes) that enable native gestures and settings for our touchpad (Just like Apple's Magic Trackpad). However this version is in current development and those willing to test should expect bugs. 

I2C.zip

Very nice, thank you for this! Do you happen to know if the pinning for the 9560 is the same?

Link to comment
Share on other sites

4 hours ago, goodwin_c said:

Thanks. That is what i was thinking - on my machine it didn't catch TPD1 device. Even, i don't see TPD1 in IOReg. Will try to debug ACPI to find out what is going on.

same here, TPD* missing.

to be honest i'm a lil bit confused... i'm pretty sure the ELAN Touchscreen is connected with USB, not I2C...

Link to comment
Share on other sites

3 hours ago, wmchris said:

same here, TPD* missing.

to be honest i'm a lil bit confused... i'm pretty sure the ELAN Touchscreen is connected with USB, not I2C...

Try to replace your SSDT-XOSI with next code:

DefinitionBlock ("", "SSDT", 2, "hack", "XOSI", 0x00000000)
{
    External (_SB.TBFP, MethodObj)
    External (USTP, UnknownObj)
    Name (CNT1, Zero)
    Method (XOSI, 1, NotSerialized)
    {
        CNT1++
        IF (CNT1 == 0x1)
        {
          \_SB.TBFP (One)
          USTP = One
        }
        Local0 = Package (0x0A)
            {
                "Windows",
                "Windows 2001",
                "Windows 2001 SP2",
                "Windows 2006",
                "Windows 2006 SP1",
                "Windows 2006.1",
                "Windows 2009",
                "Windows 2012",
                "Windows 2013",
                "Windows 2015"
            }
        Return ((Ones != Match (Local0, MEQ, Arg0, MTR, Zero, Zero)))
    }
}

This will:

- permanently enable TB controller (USB-C works like a charm :) )

- should make VoodooI2C attaching to TPD acpi device

  • Thanks 1
Link to comment
Share on other sites

works well. thank you.

btw usb-c worked well before ;-)

@hvolkoff
does the voodooi2c native branch kext also mess up with your left click (not tap)?
most physical clicks are not recognized anymore on my system, but drag and drop works ... but sometimes doesnt register the clickUP event. dunno if configured something wrong or this is just a bug

Edited by wmchris
Link to comment
Share on other sites

7 hours ago, lebish said:

Very nice, thank you for this! Do you happen to know if the pinning for the 9560 is the same?

Hi, I don't know cause I don't have a 9560 and also don't have access to one's DSDT. But it may work, considering that some of my config is derived from @KNNSpeed's files, and I made very few changes to make them compatible with 9550.

5 hours ago, wmchris said:

same here, TPD* missing.

to be honest i'm a lil bit confused... i'm pretty sure the ELAN Touchscreen is connected with USB, not I2C...

Well... I got say that I don't understand much of how that works as well, hahaha. But, from our device DSDT you can see that in the _SB.PCI0.I2C1 bus there are two devices declared:

Scope (_SB.PCI0.I2C1) {
        Device (TPD1) {
            Name (HID2, Zero)
            Name (SBFB, ResourceTemplate () {
                I2cSerialBusV2 (0x002C, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                    0x00, ResourceConsumer, , Exclusive,
                )
            })
			
            ...
        }

        Device (TPL1) {
            Name (HID2, Zero)
            Name (SBFB, ResourceTemplate () {
                I2cSerialBusV2 (0x004C, ControllerInitiated, 0x00061A80,
                    AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                    0x00, ResourceConsumer, _Y29, Exclusive,
                )
            })
	
            ...
		}

    ...
}

TPD1 is the touchpad
TPL1 should be the touchscreen

However if you check IOReg with VoodooI2C enabled:

image.thumb.png.629a57ee91bc478c75c6cabed74f3fa4.png

You can see that under I2C1 there is only TPD1 (touchpad), and on the USB controller there are some I2C nodes for the Touchscreen. So, maybe, the TPL1 device is acting as some kind of bridge between the two interfaces or something. But that is just me guessing based on my currently limited knowledge of I2C.
 

1 hour ago, wmchris said:

works well. thank you.

btw usb-c worked well before ;-)

@hvolkoff
does the voodooi2c native branch kext also mess up with your left click (not tap)?
most physical clicks are not recognized anymore on my system, but drag and drop works ... but sometimes doesnt register the clickUP event. dunno if configured something wrong or this is just a bug

Yeah physical clicks are acting weird for me too on Native and I am experience some random crashes on startup.

Link to comment
Share on other sites

2 hours ago, goodwin_c said:

Try to replace your SSDT-XOSI with next code:


DefinitionBlock ("", "SSDT", 2, "hack", "XOSI", 0x00000000)
{
    External (_SB.TBFP, MethodObj)
    External (USTP, UnknownObj)
    Name (CNT1, Zero)
    Method (XOSI, 1, NotSerialized)
    {
        CNT1++
        IF (CNT1 == 0x1)
        {
          \_SB.TBFP (One)
          USTP = One
        }
        Local0 = Package (0x0A)
            {
                "Windows",
                "Windows 2001",
                "Windows 2001 SP2",
                "Windows 2006",
                "Windows 2006 SP1",
                "Windows 2006.1",
                "Windows 2009",
                "Windows 2012",
                "Windows 2013",
                "Windows 2015"
            }
        Return ((Ones != Match (Local0, MEQ, Arg0, MTR, Zero, Zero)))
    }
}

This will:

- permanently enable TB controller (USB-C works like a charm :) )

- should make VoodooI2C attaching to TPD acpi device

Damn, thanks man. I totally forgot about adding that to the post... I too did have to make changes in SSDT-XOSI, but I only had to add the newer "windows" identifiers to it. Do you mind explaining what the CNT1 bit is about?

Link to comment
Share on other sites

3 minutes ago, hvolkoff said:

Damn, thanks man. I totally forgot about adding that to the post... I too did have to make changes in SSDT-XOSI, but I only had to add the newer "windows" identifiers to it. Do you mind explaining what the CNT1 bit is about?

afaik its for triggering power to the TB device on bootup.

Edited by wmchris
Link to comment
Share on other sites

7 hours ago, wmchris said:

afaik its for triggering power to the TB device on bootup.

Yes, it is done to be sure that part inside of "if" will be triggered only once (on first call of XOSI function), as XOSI function is used few times in original DSDT.

Link to comment
Share on other sites

I have also installed the I2C Kexts but the Touchpad doesn't work for me with this Kext. Installed also the SSDT-XOSI and the Device TPD1 is also there according to IOReg. Did I something wrong or is this a Bug? The Keyboard works normal. With the ApplePS2SmartTouchPad.kext I have no problems with my Touchpad.

Link to comment
Share on other sites

My XPS 15 9550 will not boot after install.

I followed the GitHub guide, except I used [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] and Clover from tonymac. I have installed 10.13.2 onto APFS (SSD disk only)  and it boots via Clover on the USB, but will not boot on its own. No diagnostic, just a Dell blue screen comes up saying the disk won't boot.

My BIOS is 1.4.0.

Any suggestions on what to try?

Link to comment
Share on other sites

On 3/13/2018 at 10:22 PM, hitman478 said:

I have also installed the I2C Kexts but the Touchpad doesn't work for me with this Kext. Installed also the SSDT-XOSI and the Device TPD1 is also there according to IOReg. Did I something wrong or is this a Bug? The Keyboard works normal. With the ApplePS2SmartTouchPad.kext I have no problems with my Touchpad.

Same for me. Even though removing the I2C kexts it does not work. It may be due to the SSDT-XOSI or voodooPS2daemon?

I have only tried the SSDT-XOSI as @goodwin_c suggested, not using the previous one with enabling later windows as @hvolkoff stated.

I have tried both I2C 2.0.1 and the "10.13 beta" as included in zip file of original post by @hvolkoff .

The ControllerInterrupt first two hex are "10" looking at IOReg.

I've noticed that in some cases the mouse works just fine during the login screen, but shortly after logging in it stops moving, hard to do mouse clicks, essentially unusable except for scrolling. The touchscreen, however, works perfectly.

Link to comment
Share on other sites

13 hours ago, pourhaus said:

My XPS 15 9550 will not boot after install.

I followed the GitHub guide, except I used ##### and Clover from tonymac. I have installed 10.13.2 onto APFS (SSD disk only)  and it boots via Clover on the USB, but will not boot on its own. No diagnostic, just a Dell blue screen comes up saying the disk won't boot.

My BIOS is 1.4.0.

Any suggestions on what to try?

OK, that was a quick post where I was hoping someone may have hit a similar problem.

Let me expand. As mentioned, I used U-n-i-B-e-a-s-t and Clover from t-m-86 to install _just_ the USB. That works from F12 boot menu, and is able to boot the High Sierra it installed from the SSD. I used the Clover, EFI and instructions from the GitHub repo to update/configure the High Sierra on the SSD itself (post-boot). Boot direct from the SSD does not work. I get _no_ text from the OS, it goes from BIOS boot menu to black screen for 5-10 seconds, then to Dell blue can't-boot screen.

Link to comment
Share on other sites

Just wanted to say thank you for providing the package and this tutorial for the XPS 15 9550, I found it very quick and easy to get up and running thanks to you! I ran in to 2 problems during the process which I thought I'd highlight as these were the only ones I encountered and in case anybody else is trying to do the same:

 

1) "does printf work??" - this was caused by the incorrect default "slide=0" value when using "OsxAptioFix3Drv-64.efi". Calculating the slide manually as per this tutorial fixed this for me.

 

2) "Unable to find driver for this platform" - this happened when I was using Pandora's Box to create my EFI boot USB. Manually erasing the USB to GUID structure, using the Clover installer provided in the Github package to create it and then manually installing the High Sierra installer on to the USB worked for me.

Quick question, has anybody upgraded their 10.13.3 install with the new "10.13.3 Supplemental Update" and if so, how did it go?

  • Thanks 1
Link to comment
Share on other sites

 Share

×
×
  • Create New...