AMD RADEON RX Grafikkarten ohne LILU & WhatEverGreen nutzen

  • Liebe AMD RADEON RX Nutzer,


    die Coderin "Mieze" hat es HIER doch tatsächlich geschafft, daß wir ab sofort diverse Radeon Karten, die bislang nicht "OutOfTheBox" liefen, nun auch ohne die 2 Kexte "Lilu.kext" und "WhatEverGreen.kext" sowohl unter SIERRA (macOS 10.12.x), als auch unter HIGH SIERRA (macOS 10.13.x) nativ laufen lassen können.
    Alles, was dazu benötigt wird, ist eine SSDT für eure Grafikkarte, den Patch von Mieze und ein paar kosmetische Einstellungen für das abschliessende Finetuning. Beides werde ich Euch so gut es eben geht hier näherbingen und erklären.


    1.) Wir fangen mit der Erstellung der SSDT an. Dazu benötigen wir einen IORegisteryExlplorer Log unseres (noch mit LILU und WhatEverGreen) gestarteten Macs. Sollte dann in etwa so aussehen:

    Für die Ansicht habe ich mal bewusst die Unterpunkte eingefahren, damit die Übersicht gewahrt bleibt.
    Hieraus können wir den folgenden Pfad des Steckplatzes unserer Grafikkarte entnehmen: in unserem Beispiel ist das "_SB/PCI0/PEG0/PEGP/PLX1". Das ist quasi der Startpfad in unserer kommenden SSDT.


    2.) Als nächstes benötigen wir das Programm "MaciASL", mit dem wir unsere neue SSDT für die Grafikkarte erstellen. Programm öffnen, die sich daraufhin autom. öffnende DSDT schliessen und Command-N für ein neues Dokument.
    In dieses kopieren wir als aller erstes die folgenden Zeilen:



    Sicherlich ist Euch das "WEYW" und "SameHere" bereits aufgefallen. Taucht hier bereits jeweils 2x auf und kann von Euch durch eine beliebige Zeichenkombi ersetzt werden - wobei das "SameHere" bei mir immer auch der Dateiname der finalen SSDT ist, also in diesem Beispiel wäre das dann "SameHere.aml". Das kann aber auch jeder handhaben, wie er möchte.
    Wichtig ist der Bereich zwischen den beiden Klammern "{" und "}", denn hier landet der eigentliche Code für die Grafikkarte und den Patch. In unserem oben genannten Beispiel sieht das ganze fertig eingerichtet dann so aus:



    Ich habe den Code, so gut es mir möglich war (bin selber kein Coder), versucht zu dokumentieren, damit man in etwa weiss, wofür welcher Part steht. Wenn MaciASL nun beim compelieren keine Fehler ausspuckt, speichern wir die fertige SSDT beispielsweise unter EFI/CLOVER/ACPI/patched als "AmdGfx.aml" ab und machen unseren ersten Test mit einem Neustart.
    Hier sollte man sich ein wenig mit dem CLOVER Bootloader auskennen, dann kann man nämlich für den ersten Test die Lilu und WhatEverGreen kexte noch im Ordner "EFI/CLOVER/kexts/Other" belassen und innerhalb von CLOVER deaktivieren, sodaß man, wenn etwas NICHT geht, ggf. nur die neue SSDT via CLOVER deaktiviert und der Rechner dann wieder hochfährt.


    die hier erstellte SSDT findet ihr im Anhang als Download (sample_SSDT.dsl)


    Ich habe mit dieser SSDT erfolgreich im BIOS die IGPU komplett deaktiviert und auch mein CSM steht von den Einstellungen her komplett auf UEFI (statt LEGACY) und ist ebenfalls komplett deaktiviert. Rechner startete erfolgreich, jedoch wurde einer meiner 3 Monitore nicht angesteuert - und hier kommen wir dann zum finalen Finetuning.


    3.) FINETUNING


    "Warum geht bei mir der eine Monitor nicht?" war gleichmal meine erste Frage. Unterstützt der patch etwa kein Multi-Monitor-Setup? DOCH, tut er - der Verursacher ist der altbekannte AGDC-Fix. Hier muss dafür gesorgt werden, daß der gewählte Framebuffer nicht auf die AGDC zugreift. Wie machen wir das? Ganz einfach:
    Dazu sehen wir uns mal die "info.plist" unserer durch die Grafikkarte gewählte "AMD9xxxController.kext" an. In dieser findet man die durch diesen Controller nutzbaren Framebuffer plus div. Config und Properties Einstellungen. Und unter "aty_config" findet man unter anderem die folgenden Angaben:


    <key>CFG_USE_AGDC</key>
    <true/>


    Setzen wir hier den Wert "<true/>" auf "<false/>", so wird AGDC von diesem Controller nicht mehr aufgerufen. Besser noch: sollte dieser Eintrag unter eurem genutzten Framebuffer stehen, ändert Ihr ihn dort von TRUE auf FALSE und lasst ihn unter den aty_config Einstellungen so stehen, wie er ist. Dann gilt die Einstellung von Euch nur für den von Euch eingesetzten Framebuffer. Ist dieser Eintrag für Euren Framebuffer nicht vorhanden, einfach an der passenden Stelle einfügen. Sollte dann in etwa so aussehen:


    GRÜN = disabled nur für den gewählten Framebuffer - ROT = enabled für den 9500Controller


    Um die Datei (info.plist) zu ändern und die geänderte Version zu nutzen, OHNE die original AMD9xxxController.kext zu modfizieren, bin ich wie folgt vorgegangen:
    ! ich empfehle an dieser Stelle mal ganz bewusst die Installation der XTools, da hier der Umgang mit info.plist Dateien um ein vielfaches einfacher ist, als diese schonmal recht umfangreichen Dateien jedesmal mit einen Texteditor zu bearbeiten !


    info.plist aus der AM9xxxController.kext auf den Desktop KOPIEREN (nicht verschieben). Kopie via Texteditor öffnen und nach folgenden Zeilen suchen und diese in die Zwischenablage kopieren: (hier dient der Teilbereich aus der AMD9500Controller.kext als Beispiel)



    info.plist eurer FakeSMC.kext öffnen und den in der Zwischenablage befindlichen Part nach folgender Codezeile einfügen:


    <key>IOKitPersonalities</key>
    <dict>


    die FakeSMC.kext info.plist speichern - FERTIG. nun koennen wir in dem gerade eingefügten Bereich nach Lust und Laune "wildern" und Werte ändern, welche sich dann auf die Einstellungen für Eure AMD Grafikkarte auswirken. ! Doch VORSICHT: nicht jeder Wert mag es, beliebig geändert zu werden !
    Und was ich heute rausgefunden habe, ist auch geil: man kann die "aty_config" sogar um solche Einträge aufstocken:


    <key>ATY,Part#</key>
    <string>113-3E366DU</string>
    <key>model</key>
    <string>Radeon RX 580</string>


    So kann man dadurch beispielweise den Namen der Grafikkarte anpassen, oder (wie hier) die Part# der Grafikkarte ändern). Durch diese beiden Einträge ist mir die folgende Einstellung geglückt: statt normaler METAL Unterstützung unterstützt die Karte nun auch "Metal: Unterstützt, Funktionsset macOS GPUFamily1 v3" !!!
    Ich kann hier also beliebig probieren und patchen, solange ich annähernd weiss, was ich da tue. Und merke: es ist immer wichtig, einen Ersatz CLOVER-Bootstick parat zu haben, von dem aus man den Rechner wieder erfolgreich booten kann, um misslungene Einstellungen zurückzusetzen.


    Nun wünsche ich viel Spass mit einer LILU.kext und WhatEverGreen.kext freien AMD RADEON Grafikkarte.


    UPDATE #1: ich habe hier auch mal einen AMD9xxxControllerPatcher.kext angehängt. Ist ein DummyKext, sodass man nicht mehr die FakeSMC.kext patchen muss (wie oben im Text beschrieben), sondern einfach diesen DummyKext den eigenen Bedürfnissen anpassen (folgt in einer separaten Anleitung).
    dieser DummyKext ist derzeit auf mein Setup abgestimmt und soll Euch nur als Richtlinie dienen. Wie gesagt: Anleitung zum anpassen dieses DummyKextes folgt in einer späteren Anleitung - bin zu müde das jetzt noch zusammenzufriemeln.


    UPDATE #2: ich habe die SSDT nochmal angepasst:ich habe den Part mit


    Code
    1. Method (DTGP, 5, NotSerialized)
    2. {
    3. .
    4. .
    5. .
    6. Return (Zero)
    7. }


    rausgeschmissen und dafür in Zeile 24 folgen Code eingefügt: External (DTGP, MethodObj)
    Diese Zeile bewirkt das die DTGP Methode aus der systemeigenen DSDT, oder der von Euch gepatchten DSDT aufgerufen wird. Das macht den Code für die hier beschriebene SSDT übersichtlicher.


    = = = = = = = = = = = = = = =


    Anleitung zum Thema "Warum einen Dummy.kext einsetzen":


    Aus der bisherigen Diskussion zu diesem Beitrag von mir ist relativ schnell zu erkennen, daß viele von Euch sich fragen, wozu der Dummy.kext gut sein soll.
    Ich möchte es Euch an dieser Stelle gerne näher bringen - habe jedoch vorher einen guten Rat an jeden von Euch: installiert Euch unbedingt die Apple XCode (auch wenn diese im Download 5GB+ gross sind) - ES LOHNT SICH, da die Bearbeitung der im folgenden beschrieben Routinen damit um ein vielfaches einfacher umzusetzen sind.


    Der Grundgedanke von mir für einen Dummy.kext ist der folgende: die AMD9xxxController Kexte enthalten jeweils eine "config.plist", die dazu dient, diverse Werte, die der Controller nutzt, vorzudefinieren. Bedeutet im Umkehrschluss: man kann die Werte ändern, bzw. nach Bedarf anpassen. Damit man eine solche Anpassung nicht in der originalen Apple Kext macht, welche dann ein Update auf Version macOS 10.x.x nicht überleben würde, weil Apple auch an den AMD9xxxController Kexten etwas modifiziert hat, basteln wir uns einfach einen Dummy.kext für den von unserer AMD GFX-Karte genutzten Controller. Ihr findet im Anhang an diesen Post einen solchen Dummy.kext, den Ihr (hoffentlich ;-) ) nach dieser Anleitung an Eure Bedürfnisse anpassen könnt.


    Schauen wir uns also mal die "info.plist" der original Apple AMD9520Controller.kext an:

    Der in diesem Screenshot umrandete Teil ist der von mir bereits angesprochene Teil, in dem die verschiedensten Settings für diesen Controller festgelegt sind. Was einem zuerst ins Auge fällt ist, daß dieser Controller die Framebuffer CARONI, ELQUI und FLORIN unterstützt. Desweiteren wird dieser Controller nur von AMD Karten genutzt, deren Device-ID 67E0, 67EF, 67FF, 67C0 oder 67DF lauten. Damit Ihr also den korrekten Controller patcht, ist es wichtig, das ihr wisst, welchen Controller eure Grafikkarte beim booten wählt. Das findet Ihr raus, indem ihr Euren Hackintosh bootet und dann mittels IORegistryExplorer den Bereich Eurer genutzten Grafikkarte aufruft (siehe erster Screenshot am Anfang dieses Beitrags). Die Einstellungen von "CFBundleIdentifier" bis "IOProviderClass" bleiben bitte unberührt und werden keinesfalls geändert - andernfalls wird die finale Fassung Eures Dummy-Kexts nicht funktionieren.


    Schauen wir uns mal die aufgeklappten Einstellungen von "aty_config" und "aty_properties" an:

    WOW, viele Einstellmöglichkeiten! Doch das ist nur ein Bruchteil dessen, was der Controller wirklich zu bieten hat. Fragt mich bitte nicht, was jeder einzelne Wert zu bedeuten hat, denn ICH WEISS ES NICHT. Einige davon teilweise selbsterklärend (dazu komme ich noch), andere deuten weder vom Namen noch sonst irgendwie auf deren Funktion! Und für die experimentierfreudigen unter Euch zeigt sich hier auch schon der erste Vorteil dieses Dummy Kextes: haben wir einen Wert geändert und der Rechner bootet nicht mehr sauber oder womöglich gar nicht mehr, können wir diesen Dummy Kext einfach im CLOVER Bootmenü deaktivieren, sodaß der Mac wieder auf den original Apple AMDController zugreift und somit wieder die ursprünglichen Werte geladen werden. Zweiter Vorteil: ich kann die "CFG_"- und "PP_"-Einstellungen um viele weitere Werte ergänzen. Jetzt fragt Ihr Euch sicherlich: um welche denn zum Beispiel? Jeder Controller beinhaltet eine Liste mit ALLEN von ihm unterstützten Werten. Die sind in unserem Beispiel (AMD9520Controller.kext) dann so aus:


    nur mal die "CFG_" Werte. Noch mehr Werte findet Ihr für die "PP_"-Einstellungen:



    bis hin zu



    Ihr seht: hier kann man sich (wenn man denn will) richtig austoben.


    Nun, wie erstellt Ihr einen Dummy.Kext, der auf Euren genutzten Controller zugeschnitten ist? Ladet Euch zunächst den hier angehängten Dummy Kext "AMD9xxxControllerPatcher.kext.zip" runter und entpackt diesen beispielsweise auf dem Desktop. Öffnet diesen per Rechts-Klick - "Packetinhalt zeigen". Im darin befindlichen Contents-Ordner findet ihr die zu modfizierende "info.plist". Das selbe macht Ihr mit einer Kopie der von Euch ermittelten AMD9xxxController.kext aus "System/Library/Extensions". Seit ihr meinem Rat gefolgt und habt Euch XCODE installiert, sollte sich euch folgendes Bild zeigen:

    Screenshot der original Apple AMD9520Controller.kext "info.plist"



    Screenshot der Dummy Kext "info.plist"


    Klickt das Dreieck vor "IOKitPersonalities" des von Euch ermittelten Controllers an und anschliessend auf "Controller", dann Command-C zum kopieren in die Zwischenablage und schliesst die "info.plist" des Apple Controller.kext. Öffnet nun den Dummy.kext auf die selbe Weise (Rechtsklick blabla) und markiert wieder den Eintrag "Controller", löscht diesen durch drücken der Backspace-Taste, markiert dann "IOKitPersonalities" und drückt Command-V, um den Inhalt der Zwischenablge ("Controller" der original Datei) unter dem markierten "IOKitPersonalities" einzufügen. Dann sollte die Dummy.kext nun so aussehen, wie im Screenshot direkt über diesen Zeilen. Jetzt noch Command-S zum sichern der "info.plist" und umbenennen der ".kext" Datei wie es euch gefällt, beispielsweise in "AMD9520ControllerPatcher.kext" (um bei unserem Beispiel zu bleiben).


    Der Grundstock ist gelegt, der nutzbare Dummy.kext ist fertig und kann unter "EFI/CLOVER/kexts/Others/" zum Einsatz kommen. Jetzt kann man anfangen, mit den einzelnen Werten zu "spielen" und diese ggf. zu ändern. Neustarten, schauen ob der Rechner noch bootet und gucken, was sich geändert hat. Aber ich warne an dieser Stelle noch einmal: das sollten wirklich nur erfahrene User tun, denn ich weiss aus eigener Erfahrung, das nicht jede der CFG_ oder PP_ - Einstellungen beliebige Werte verträgt.


    Aber, und das ist das geniale: es gibt Settings, die von Hause aus auf "enabled" = 1 oder "disabled" = 0 stehen und bei denen man einfach mal durchprobieren kann, was passiert, wenn man diese "enabled" oder "disabled". Ich erkläre Euch das an Hand eines Beispiels:


    Es gibt folgenden Wert für die "aty_properties":


    Wer sich mit den AMD-Treibern der RX-Karten unter WINDOWS ein wenig auskennt, der weiss, daß WATTMAN für die GPU-temperaturabhängige Lüftersteuerung zuständig ist. Unter Apple steht die Einstellung "PP_DisableAutoWattman" auf "true" = "1", was bedeutet, sie ist standardmäßig deaktiviert (disabled = true).
    Nun können wir hergehen, und bei unserem Dummy.kext diesen Wert hinzufügen und in"PP_DisbledAutoWattman = 0" ändern und sie somit aktivieren (Disabled = false). Klingt zunächst erstmal kompliziert, weil warum wird diese Funktion mit dem Wert "0" gesetzt, wenn doch "0" = AUS und "1" gleich EIN bedeutet? Weil die
    Funktion "PP_Disable..." heisst. Es gibt auch Funktionen wie "PP_Enable..." und da zählt dann tatsächlich: "0" = AUS, "1" gleich EIN. Also merke:


    "PP_Disable..." dann "0" = die Funktion wird genutzt, "1" = die Funktion wird NICHT genutzt
    "PP_Enable..." dann "1" = die Funktion wird genutzt, "0" = die Funktion wird NICHT genutzt


    Wie bekommen wir diese Funktion nun in unsere Dummy.kext "info.plist" ?
    Öffnet Eure Dummy.kext "info.plist", klickt auf das Dreieck vor "aty_properties", klickt auf irgendeine vorhandenen "PP_..." Eintrag und kopiert diesen via Command-C in die Zwischenablage. Markiert nun den letzten "PP_"-Eintrag und drückt Command-V zum Einfügen der Zwischenablage:



    Jetzt doppeklick auf den soeben eingefügten Eintrag (vorne auf den Namen, hier eben "PP_DisableCAC - 2") und ändert diesen in "PP_DisableAutoWattman", die "0" bleibt stehen, damit WATTMAN genutzt wird und eben NICHT gedisabled wird. FERTIG.



    Speichern - rebooten und über eine temperaturgeregelte Lüftersteuerung der Lüfter Eurer Grafikkarte freuen.
    ! ACHTUNG ! - das hier genannte Beispiel gilt NUR für AMD Karten der RX-Serie. Karten der HD-Serie unterstützen kein WATTMANN.


    Das war es auch schon mit der Erklärung, warum eine Dummy.kext von Vorteil sein kann. Letzlich entscheidest DU, ob DU eine nutzt oder nicht. Viel Spass für den Fall daß...


    EDIT:
    Der User "modzilla" hat mich auf folgenden Umstand aufmerksam gemacht, welchem einem das Nutzen einer Dummy.kext erspart. Die hier soeben beschrieben Werte kann man auch direkt in der erstellten SSDT einsetzen. Das Ganze muss dann ungefähr so aussehen:



    Einfach in dem Bereich hinzufügen, an dem in Eurer SSDT die Werte für den Framebuffer, den Slot oder den Kartennamen steht.

  • Vielen Dank dir / euch für die Informationen.
    Ich habe nicht so ganz verstanden, was du mit MacOS GPUFamily1 v3 meinst und verstehe daher wahrscheinlich auch nicht, welchen Mehrwert mir die SSDT Lösung statt der beiden Kexte bietet. Dieser Weg ist ja definitiv Zeitaufwendiger und hat daher bestimmt auch Vorteile sonst bräuchte man ihn ja nicht oder?

    iMac 15,1 - Gigabyte GA-Z77-DS3H Rev. 1.0
    i5 3750K :: PowerColor RedDevil RX480 8 GB :: 32 GB Ram DDR 3 :: macOS 11.1 @ Clover r5 & Windows 10 Pro
    MacBook Pro 15,4 - Terra Mobile 1550 :: 15,6" FullHD
    i5-8265U :: Intel UHD620 :: 8 GB RAM :: DW1560 :: macOS 10.15.5 @ Clover r5096

    MacBook Pro 8,1 - 13" Anfang 2011 :: MacBook Air 7,2 - 13" Anfang 2015


  • Vorteil für MICH in zweierlei Hinsicht:


    a) ich habe 2 Kexte weniger, um die ich mich "kümmern" muss (auf Updates checken etc) und die ich unter Umständen als Fehlerquelle einschliessen müsste, und
    b) da ich eh schon eine GFX-SSDT benutzt habe, ist diese Lösung für mich ein segen, da ich diese (einmal angelegt) eher selten anpassen muss - sofern sich nicht grundlegend im BIOS etwas ändert oder ich das Motherboard wechsle.


    Sprich: ja, sie ist zeiaufwändiger, aber: einmal einrichten and forget about it ;-)


    PS: Lilu habe ich auf meinem Hackintosh wirklich nur wegen der WhatEverGreen Lösung benutzt. Für weitere Zwecke, die Lilu bietet benötige ich diese Kext nicht, da bei mir sonst alle von mir genutzte HW tatsächlich "OutOfTheBox" läuft.
    Thunderbolt wäre noch so ein Thema, wo ich händeringend auf eine ähnlich galante SSDT-Lösung warte, um angeschlossen TB-Geräte auch im Systemprofiler unter der Rubrik THUNDERBOLT angezeigt zu bekommen. Habe mich selbst schon dran versucht - bislang leider ohne Erfolg.

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

    Einmal editiert, zuletzt von Mork vom Ork ()

  • Ich werde es mal morgen oder zum Ende der Woche ausprobieren, wenn ich Zeit und die Ausgeschlafenheit dafür habe.
    Dass jemand noch die Lösung DSDT dafür findet hätte ich nicht gedacht, schließlich war das ja mit Whatevergreen eigentlich durchgekaut.
    Da diese Lösung hier auch noch Updatesicher sein sollte wird die sich wohl zu ersten Wahl derjenigen entwickeln, die wegen HDMI Audio eh eine gepatchte DSDT oder SSDT haben.
    An dieser Stelle Hut ab an Mieze.

    Original Apple: MacBook Pro 14 2021 - macOS Sonoma

    Hackintosh: Lenovo M710q - macOS Sonoma

  • initial Post updatet for the first Time.


    NEU:
    DummyKext zum ändern der AMD9xxxController.kext "info.plist". Hier kann man in aller Seelenruhe die versch. Werte ändern, ohne dabei auf die original Apple AMD kexte zugreifen zu müssen.
    Funktioniert ein geänderter Wert nicht wie erhofft und der Rechner hängt sich auf, einfach via CLOVER diesen DummyKext excluden (vom Injecten ausschliessen) und Rechner bootet die AMD kexte mit den original Werten.

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

    Einmal editiert, zuletzt von Mork vom Ork ()

  • Unfassbar wie du da dran bist was das angeht.


    Sehr geile Sache :D

    MacBook Pro 15.4" Late 2015
    iPhone 7+ 128GB




    Stay calm 'til valhall

  • Vielen Dank für die Erklärung! Das mit der DummyKext klingt super.

    iMac 15,1 - Gigabyte GA-Z77-DS3H Rev. 1.0
    i5 3750K :: PowerColor RedDevil RX480 8 GB :: 32 GB Ram DDR 3 :: macOS 11.1 @ Clover r5 & Windows 10 Pro
    MacBook Pro 15,4 - Terra Mobile 1550 :: 15,6" FullHD
    i5-8265U :: Intel UHD620 :: 8 GB RAM :: DW1560 :: macOS 10.15.5 @ Clover r5096

    MacBook Pro 8,1 - 13" Anfang 2011 :: MacBook Air 7,2 - 13" Anfang 2015


  • @Mork vom Ork Vielen Dank für deinen Beitrag. :thumbsup:


    Anmerkung: Ich konnte erst kompilieren, nach dem ich den Punkt nach Device (HDAU) entfernt habe.

    MfG, docplag



  • Ganz nett, aber wenn man noch einen Dummykext benötigt kann man doch auch gleich Whatevergreen nutzen?!

    Liebe Grüße, alex


     Mac mini Late 2020 – M1 – 16GB RAM – 256GB SSD

     MacBook Pro 15” Late 2015 – i7 4980HQ – 16GB RAM – 256GB SSD

     MacBook Pro 13” Late 2014 – i5 4278U – 8GB RAM – 120GB SSD

    iPhone 13 – iPhone 8 Plus – iPad Pro 12,9" – AirPods 1. Gen – AirPods Pro – Apple Watch S5 44mm




  • Wird ja nicht benötigt, erleichtert nur ein bisschen was. Sehe es aber auch so. Für mich als Anfänger ist es leichter, zu schauen ob meine Kexte aktuell sind als die Arbeiten an SSDT. Das ist für mich noch ein Buch mit naja so einigen Siegeln :-)

    iMac 15,1 - Gigabyte GA-Z77-DS3H Rev. 1.0
    i5 3750K :: PowerColor RedDevil RX480 8 GB :: 32 GB Ram DDR 3 :: macOS 11.1 @ Clover r5 & Windows 10 Pro
    MacBook Pro 15,4 - Terra Mobile 1550 :: 15,6" FullHD
    i5-8265U :: Intel UHD620 :: 8 GB RAM :: DW1560 :: macOS 10.15.5 @ Clover r5096

    MacBook Pro 8,1 - 13" Anfang 2011 :: MacBook Air 7,2 - 13" Anfang 2015


  • Das ist für mich noch ein Buch mit naja so einigen Siegeln

    Für mich auch, ich werde es aber mal probieren.


    Schau dir mal den Workshop von @al6042 an ;)



    --------------


    Muss man die Sache immer aktuell halten oder reicht es, die Geschichte einmal zu machen und dann nicht mehr?

    Liebe Grüße, alex


     Mac mini Late 2020 – M1 – 16GB RAM – 256GB SSD

     MacBook Pro 15” Late 2015 – i7 4980HQ – 16GB RAM – 256GB SSD

     MacBook Pro 13” Late 2014 – i5 4278U – 8GB RAM – 120GB SSD

    iPhone 13 – iPhone 8 Plus – iPad Pro 12,9" – AirPods 1. Gen – AirPods Pro – Apple Watch S5 44mm




  • So, auch auf der RX560 läuft das mit HS. Musste den Dummy Kext nutzen, um die AGDC abzuschalten.
    Das ganze sieht dann aus wie auf dem Bild.
    Integriert hab ich den Patch in die DSDT. Da ohne Probleme anwendbar.


    Gefühlt dauert es mit der Methode etwas länger, bis ein Bild angezeigt wird.


    DSDT Eintrag:


    P.S.: Kennt eigentlich jemand einen Weg, wie man sein angestecktes Display als Internes Display erscheinen lassen kann? Leider funktioniert Nightshift nicht über HDMI.

  • @ductator Da ich auch die RX560 habe, kann ich mir ja einfach deine Part klauen, und in meine DSDT packen?!

    Liebe Grüße, alex


     Mac mini Late 2020 – M1 – 16GB RAM – 256GB SSD

     MacBook Pro 15” Late 2015 – i7 4980HQ – 16GB RAM – 256GB SSD

     MacBook Pro 13” Late 2014 – i5 4278U – 8GB RAM – 120GB SSD

    iPhone 13 – iPhone 8 Plus – iPad Pro 12,9" – AirPods 1. Gen – AirPods Pro – Apple Watch S5 44mm




  • Naja einfach kopieren würde ich den nicht, du muss schon eine fertige DSDT haben (GFX0 -> IGPU und ein GFX0 Device unter PEGP oder ähnlich).
    Dann noch die entsprechenden Einträge im Block anpassen (Card#, ROM, model)

    Original Apple: MacBook Pro 14 2021 - macOS Sonoma

    Hackintosh: Lenovo M710q - macOS Sonoma

  • Eine DSDT habe ich.
    Ich habe mir das aber schon angesehen und für (mich) zu kompliziert empfunden. Da bleibe ich bei Whatevergreen.

    Liebe Grüße, alex


     Mac mini Late 2020 – M1 – 16GB RAM – 256GB SSD

     MacBook Pro 15” Late 2015 – i7 4980HQ – 16GB RAM – 256GB SSD

     MacBook Pro 13” Late 2014 – i5 4278U – 8GB RAM – 120GB SSD

    iPhone 13 – iPhone 8 Plus – iPad Pro 12,9" – AirPods 1. Gen – AirPods Pro – Apple Watch S5 44mm




  • initial Post updated:


    NEU:
    sample_SSDT.aml angepasst und die Method (DTGP) entfernt. Code der SSDT dadurch noch übersichtlicher - setzt jedoch voraus, das Eure DSDT bereits mit der Method (DTGP) gepatched ist.

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

    Einmal editiert, zuletzt von Mork vom Ork ()

  • Ok Korrektur.
    DSDT war einfach nur falsch implementiert. Um die korrekte Anzahl an Bildschirmen zu erkennen, muss noch

    Code
    1. "@x,name",
    2. Buffer (0x09)
    3. {
    4. "ATY,Acre"
    5. },

    (x ist dabei eine aufsteigende Nummer, beginnend bei 0, Acre ist ein beispielhafter Framebuffer, aus Buffer am Besten 0x09 entfernen vor dem Compilern)
    mehrmals eingesetzt werden.
    Damit wird der Bildschirm dann auch entsprechend schnell erkannt.
    Man kann auch einfach 4-5 davon implementieren in der DSDT, die überzähligen werden dann einfach ignoriert (sollte am Besten der Anzahl der Ports an der Grafikkarte entsprechen). Die richtige Anzahl der Einträge kann man mit dem DPCIManager und Whatevergreen herausfinden.
    Dummy Kext ist dann auch nicht mehr notwendig bei der RX560.
    Den DSDT Code habe ich angepasst.


  • Um die korrekte Anzahl an Bildschirmen zu erkennen, muss noch

    Code
    1. "@x,name",
    2. Buffer (0x09)
    3. {
    4. "ATY,Acre"
    5. },

    (x ist dabei eine aufsteigende Nummer, beginnend bei 0, Acre ist ein beispielhafter Framebuffer, aus Buffer am Besten 0x09 entfernen vor dem Compilern)
    mehrmals eingesetzt werden.
    Man kann auch einfach 4-5 davon implementieren in der DSDT...


    Nicht falsch, aber muss man nicht einmal, da hier eh keine unterschiedlichen Framebuffer angegeben werden sollten (und wenn doch, zählt nur der erstgenannte), reicht es, wenn man diesen nur für "@0,name" angibt.
    Da CLOVER die Anzahl der Ports selber ermittelt, werden die restlichen gefundenen Ports ebenfalls mit dem unter "@0,name" angegebenen Framebuffer bestückt.

    ASUS WS X299 SAGE/10G • Intel Core i9-7920X 12-Core 2.9GHz • 128GB RAM • ASRock Radeon VII Phantom Gaming • 2x Samsung 980 NVMe M.2 SSD 1 TB
    Custom Wasserkühlung • Thermaltake TheTower 900 • 1x SAMSUNG 49" @ 5120 x 1440 (100Hz) via DP • LG OLED 55" TV @ 3840 x 2160 (100Hz) via HDMI
    WINDOWS 11 ENTERPRISE INSIDER (PRO950 NVMe) • macOS BIG SUR und MONTEREY latest Build (jeweils auf Samsung 980 NVMe) • OpenCore always latest

    Einmal editiert, zuletzt von Mork vom Ork ()

  • Hat bei mir halt nicht geklappt (kein Inject ATI im Clover aktiviert). Monitorerkennung ging ohne Dummy erst nicht, mit Dummy dann deutlich langsamer als mit Whatevergreen (Monitor erst wieder mit Signal, nachdem der Desktop voll geladen war).
    Mit manuell eingefügten Ports erkennt der den Monitor deutlich schneller, ich erlebe dann noch die Endphase vom Bootscreen mit und Dummy brauche ich auch nicht.


    edit: ich kann da nachher gerne die Screenshots nachliefern, dass das so wie von dir angegeben nicht geklappt hat bei mir. Da war definitiv das manuelle einfügen der Displayausgänge notwendig, was durch meinen Wintrag vorgenommen wird.

    Original Apple: MacBook Pro 14 2021 - macOS Sonoma

    Hackintosh: Lenovo M710q - macOS Sonoma

    Einmal editiert, zuletzt von ductator ()

  • Wie siehts den mit Metal 2 aus