Jump to content

Need help to swap framebuffers on Dell XPS 2720


Recommended Posts

Hi everybody. I have an unusual problem with my Dell XPS 2720. At least this one is new to me !


This is an All-In-One Haswell desktop and I've got Mojave 10.14.1 running pretty well on it except for one strange issue.


The internal display shows up as AppleDisplay under [email protected] and if I connect an external display to the HDMI port that shows up as AppleDisplay under [email protected] There is a little trick that I need to do to actually get the 2nd display to appear the first time which is not a big deal but the big problem is that if the system sleeps, it will then KP upon wake if and only if an external disply is connected to the HDMI port.


I have tried defining this system as both an iMac14,1 and iMac14,2 with the same result. iMac15,1 won't recognize an external display.


I assume that this is due to the displays being in the opposite places from where the OS expects them to be.


Can I swap the framebuffers with kext patches in Clover ? Or is DSDT/SSDT patching the way to go ?


Any guidance much appreciated :)

Link to comment
Share on other sites

Thanks for your reply !


Please advise how you would like me to generate a 'debug' file.


Not much of a trick to get the external display to show, really.


Seems as thought it's always active but just not receiving the proper resolution mode initially as the external monitor's green light is on solid but with (backlit) black display at boot up.


I simply click "Gather Windows" on SystemPreferences->Displays to get the configuration panel for the external display to show up on my primary internal display. Then I switch it to Scaled and purposely select an unsupported resolution like 720p. Then when I immediately switch back to "Default for Display", the external display works and stays that way.


Unfortunately, if I sleep, the system will then reboot on wake. This does not happen if I do not connect the external display.


I should also mention that if I connect the external display after boot up, the system promptly reboots. So the external display must be connected prior to boot up to work at all.  However, if I disconnect the external display then the primary display does go black for a moment but then bounces right back and all is well.


In the meantime, I have tried changing the SMBIOS designation to Macmini7,1 but end up with the exact same result.


Interestingly, I got a hold of an ioreg file for a genuine iMac14,1 and the primary display actually shows up as an AppleBacklightDisplay under [email protected] which I totally did not expect.


I figured that it would live under [email protected] where AGPM lives.


So, now I'm just more confused, lol !


I have enclosed 4 ioregs. 1 for the system with just an internal display, one with the external HDMI display connected before my fix and one after my fix and also one from a genuine iMac14,1. Hope this helps to get things rolling :)


I had thought that getting my primary/internal display to land under [email protected] and my external HDMI display to land under [email protected] might fix everything but maybe that's a flawed assumption on my part :(



Link to comment
Share on other sites

You nailed it !


Added your patch and all is 👌


I rebooted and then attached the external HDMI display and it just worked, no panic/restart.


I sleep the system with 2 displays and it wakes up perfectly every time.


And of course, the external display is recognized just fine without the need to set it a wrong res and then reset it back to a good one.


So could you please explain exactly what this patch is changing ?


What I think that I understand is that it's applied to [email protected] (105) and changes the port type from DP(04) to HDMI(08).


But [email protected] is where my internal display attaches while my external HDMI display actually attaches to [email protected]


At least that's what I assumed since that's where the new AppleDisplay appears when I connect the external HDMI display.


What does swapping the 2 bytes 09->12 immediately after the 0105 do ?


If you wouldn't mind expanding on these points, I would sure love to learn.


Thank you so much. This is a really great site.


You and Herve particularly have been so consistently amazing over the years !


I do have one last strangeity and I apologize if it's offtopic here but ...


This system will KP at middle boot right after FakePCIID.kext loads about every 1 out of 4 times.


Seems to be a timing thing. KP trace flies by really quickly but seems to involve AppleSMC.kext.


I am running the very latest FakeSMC, FakePCIID, Lilu, etc.

Link to comment
Share on other sites

  • Moderators

Hervé explained it best here


Your internal monitor is on port #6 [email protected], while HDMI is on port #5 [email protected], hence why I patched port #5, changing the priority from 09 to 12 (known issue on some Haswell when external monitors are connected).

You're thinking of [email protected], port 0 like a laptop, but in your system port 0 is at [email protected], same as on the real IMac.

 Post your debug file

Link to comment
Share on other sites

  • Moderators

Get rid of FakePCIID_Intel_HD_Graphics.kext + FakePCIID.kext and add WhateverGreen.kext

Sinetek-rtsx.kext <- does it work for the SD Card Reader?

VoodooPS2Controller.kext <-not needed for Desktop

AppleShippingDrive.kext <- not sure what's it for

FaceTime.kext <- not sure what's it for

SSDT.aml <-- not needed for Desktop

Link to comment
Share on other sites

OK !  Finally made it back. Sorry for the delay but life gotta little busy there.


So, to address your comments ...


No, Sinetek-rtsx.kext does NOT make my sD reader work. The kext loads and attaches to the proper device but that's all. So, it's removed now.


I am embarrassed to say that I did not realize that VoodooPS2Controller was not needed for desktops. I guess that I've been working on laptops for so long that most of the desktops that I converted prior had PS2 keyboards and mice. Ooops ! OK, that's out too.


AppleShippingDrive and FaceTime kexts are primarily to fix "cosmetics".  They simply inject vendor/device ids of known Apple devices in place of the actual.  When configured properly, they allow an installed optical drive to show up as an "Apple Shipping Drive" and a webcam to be treated as a "FaceTime HD Camera (Built-in)". In rare cases, they can actually help the devices perform better. In fact, in the case of this XPS2720, the webcam was only showing me an orange blob in PhotoBooth until I added FaceTime.kext, Now it performs perfectly ! Sometimes the FaceTime.kext can have the opposite affect and stop a webcam from working. AppleShippingDrive.kext never seems to hurt anything and IS only 100% cosmetic in my experience.


Hmmm, always thought that generating an SSDT for my CPU using the fab scripts first by RevoGirl and later by PikerAlpha was the way to for any system. OK. So I removed SSDT.aml from ACPI->patched and I do still have the same 29 P-States and sleep working fine, Cool !


I did give WhateverGreen a try when I was attempting to figure out the dual display patch for this XPS2720. I removed FakePCIID_Intel_HD_Graphics.kext + FakePCIID.kext and added WhateverGreen.kext only to be greeted by a pink hued desktop. Plus, still some KPs !


So it was more like WhateverPink for me


I do a couple of Clover patches in the config, one is GFX0->IGPU,

Plus I modify my DSDT fairly extensively. I'm kinda old school.


I generated a new debug package and had a glance at the last panic log ...


*** Panic Report ***
panic(cpu 0 caller 0xffffff7f89225c1d): "DSMOS: SMC returned incorrect key: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/DontStealMacOS/DontStealMacOS-27.200.2/Dont_Steal_MacOS.cpp:221
Backtrace (CPU 0), Frame : Return Address
0xffffff811255b970 : 0xffffff80067aeafd
0xffffff811255b9c0 : 0xffffff80068e85a3
0xffffff811255ba00 : 0xffffff80068d9fca
0xffffff811255ba70 : 0xffffff800675bca0
0xffffff811255ba90 : 0xffffff80067ae517
0xffffff811255bbb0 : 0xffffff80067ae363
0xffffff811255bc20 : 0xffffff7f89225c1d
0xffffff811255bd60 : 0xffffff7f89225a7e
0xffffff811255bd70 : 0xffffff8006e28a7a
0xffffff811255bdc0 : 0xffffff8006e345ab
0xffffff811255bdf0 : 0xffffff8006e34536
0xffffff811255be20 : 0xffffff7f89225a64
0xffffff811255be40 : 0xffffff8006e2c65b
0xffffff811255be80 : 0xffffff8006e2c3a1
0xffffff811255bf00 : 0xffffff8006e2b8f7
0xffffff811255bf50 : 0xffffff8006e2d3c6
0xffffff811255bfa0 : 0xffffff800675b0ce
      Kernel Extensions in backtrace:
            dependency: com.apple.kec.corecrypto(1.0)[0F77793D-78A0-3EA4-B2AC-A287F438DE3A]@0xffffff7f872ae000
            dependency: com.apple.driver.AppleSMC(3.1.9)[9FAF842D-CCF4-3F6A-893D-DD542139F128]@0xffffff7f87a7e000


Could this be related to FakeSMC.kext ?




Link to comment
Share on other sites


  • Create New...