You need to be a member in order to leave a comment
Already have an account? Sign in here.
Sign In NowSign up for a new account in our community. It's easy!
Register a new accountDanke ST3R30
Es ist egal, ob ich den HDMI- oder DisplayPort-Anschluss nutze. In beiden Fällen bleibt der Monitor nach Sleep schwarz. Ich habe mich nochmal am Intel iGPU Patching Guide versucht, aber ohne Erfolg. Seltsamerweise wird der DisplayPort von IOReg als HDMI identifiziert. Patche ich ihn zu DisplayPort wird darauf gar kein Signal ausgegeben.
Sleep bei dem Mini-PC kann nur ein Profi zum Laufen bringen. Da fehlt mir die Kompetenz.
Danke mobodick !
Das github-Repository ist zwar in Chinesisch, aber Deepl konnte es übersetzten. Es handelt sich dort um das Sky Lake Vorgängermodell, aber damit gibt es identische Probleme. Hier die Übersetzung von Deepl der wichtigsten Abschnitte:
Daraus schließe ich, dass Sleep und HDMI nicht funktionieren werden. Wenn dann nur der DisplayPort. Mein erster Versuch neben dem MacMini8,1 noch einen iMac17,1 im DataHub zu konfigurieren war kein Erfolg. Die Graphikausgabe blieb in der zweiten Bootphase und danach gänzlich aus. Ich werde von weiteren Versuchen berichten.
====== EDIT 1 =======
Weitere Experimente einen zusätzlichen DataHub-Eintrag mit einem iMac zu erstellen haben nicht zum Erfolg geführt. Seltsamerweise ist in dem chinesischen github-Repository für den HP Elite Slice G1 nur ein Eintrag für einen MacMini8,1 vorhanden. Ein DataHub-Eintrag fehlt. Ich frage mich ob es sich evlt. um einen Copy-Paste-Fehler aus dem Repository für den HP400G2DM handelt?
An dieser Stelle gebe ich meine Versuche die Graphik nach Sleep zurückzuerhalten auf. Das ist bei diesem PC zu problematisch, als dass ich es mit meinem Wissen lösen könnte. Sofern es überhaupt machbar ist.
Vielen Danke an alle, die meinen Beitrag gelesen und sogar einen Rat gegeben haben!
Kurzes Update zum gegenwärtigen Stand.
Ich habe zwei config.plist-Dateien, die eigentlich gleich gut/schlecht funktionieren. Eine für einen Mac Mini 8.1, die andere für einen iMac 18.1. Die Dateien unterscheiden sich nur in den Angaben von SystemProductName und der Graphik-Konfiguration via PciRoot(0x0)/Pci(0x2,0x0). Sleep scheint zu funktionieren. Aber beim Aufwachen fehlt nach wie vor die Graphikausgabe.
Bei Angabe eines iMac 18.2 waren die Farben gestört (z.B. wurde aus rot blau und blau war eher gelb bis orange). Vermutlich muss die Graphikkonfiguration eine andere sein als für den iMac 18.1.
OpCore-Simplify habe ich ebenfalls getestet. Bislang mit mäßigem Erfolg. Mit den durch OpCore-Simplify erstellten SSDT-Dateien war das System nicht bootfähig. Ich musste sie gegen meine vorhanden SSDTs austauschen. Damit bootete das System zwar, aber die Graphikbeschleunigung (Metal) hat gefehlt. Sleep hat gar nicht funktioniert. Vermutlich ist hier noch viel manuelle Nacharbeit nötig.
Langsam bin ich am Ende meiner Fähigkeiten angekommen. Mir fehlen die Ideen, was ich noch probieren könnte. Falls noch jemand eine Anregung hat, würde ich mich freuen.
Danke & besten Gruß!
Danke für den Hinweis auf die SMBios-Konfiguration Bob-Schmu !
Da der HP Elite Slice G2 eine Desktop-CPU verbaut hat, hatte ich nur im Desktop-Abschnitt des Dortania Guide nachgelesen. Sonst erinnert die Hardware tatsächlich mehr an einen MacMini oder Nuc. Mit diesem Hinweis habe ich weiter experimentiert und konnte meine Konfiguration etwas verfeinern:
DeviceProperties:
AAAbWQ = 00001B59
boot-args:
Das eigentliche Problem wurde damit aber nicht behoben. Sleep selbst funktioniert, aber beim Aufwachen wird keine Graphik angezeigt. Zudem habe ich herausgefunden, dass der PC ohne npci=0x2000 direkt wieder aus dem Sleep aufwacht. Allerdings ebenfalls ohne Graphikanzeige.
Einige Ideen zum Probieren habe ich noch:
Ich werde vom Fortschritt berichten. Über weitere Anregungen und Ideen bin ich stets dankbar.
Hallo zusammen,
mein Weihnachtsprojekt war / ist macOS Monterey auf einem HP Elite Slice G2 zu installieren (Intel Kaby Lake i5-7500T mit HD 630). Es soll zunächst Monterey sein, da ich eine Vorlage auf github gefunden hatte. Die meisten SSDTs & Kexts dieser Vorlage sind jedoch unnötig, weshalb ich alles nochmal mit OC 1.0.2 neu aufgesetzt habe.
Das System bootet und ist soweit lauffähig, aber Sleep bereitet Probleme. Sleep selbst scheint zu funktionieren, aber nach dem Aufwachen wird kein Bild angezeigt. Ich vermute die Intel iGPU HD 630 wird nicht korrekt aufgeweckt / neu initialisiert. Der Dortania Guide konnte mein Problem nicht lösen. Daher habe ich versucht in WhateverGreen's Framebuffer Patching Guide nachzulesen, muss aber gestehen, dass mein Verständnis an dieser Stelle zu gering ist.
Somit hoffe ich auf einen Rat aus dem Forum. Über Hinweise, wie ich die Graphik nach Sleep zurückerhalte würde ich mich freuen.
Danke & schöne Feiertage!
Hier noch die vermutlich wichtigsten Abschnitte der config.plist in diesem Kontext:
DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x2,0x0)
boot-args:
Im Anhang noch die vollständige config.plist.
Arkturus Danke für den Tipp!
Danke für die Rückmeldungen!
Ich habe noch einige Dinge ausprobiert, aber die native Auflösung im Bootbildschirm hat immer die gestörte Graphik zur Folge. Letztlich stimmt dies auch mit der Antwort von griven überein, denn:
1. das Aktivieren des CSM-Modus hat eine Auflösung von 1024x768 Pixeln zur Folge und
2. ist die Alternative zu CSM eben eine andere als die native Auflösung.
Leider hat dabei auch nur eine Auflösung von 1024x768 Pixeln funktioniert. Ich habe noch 1280x800 und 1600x900 getestet, aber daraus wurde in der Anzeige doch wieder FullHD.
Somit bleibt nur 1024 x 768 als Alternative über. Den Versuch war es wert. Danke für die Ratschläge!
bluebyte um noch auf deine Frage einzugehen: "Was soll der deiner Meinung nach sortieren. Der sortiert die Dateien höchstens in alphabetischer Reihenfolge. Mehr auch nicht."
Die Sortierung basiert auf der "CFBundleIdentifier". Angeblich werden die voneinander abhängigen kexts in der korrekten Reihenfolge geladen.
[...] It will add or remove entries as needed, and also ensures kext load order by comparing each kext's CFBundleIdentifier to all other kexts' OSBundleLibraries within their Info.plist - making sure that any kext that is relied on by others is loaded before them. [...]
Aber ich merke mir als Faustformel, dass lilu immer an erster Stelle stehen sollte. Kann nur hilfreich sein.
Heute habe ich endlich Zeit gefunden die Ratschläge zu testen. Einen wirklichen Erfolg gab es leider nicht. Trotzdem möchte ich auflisten was ich probiert habe.
Lilu an erster Stelle - vorgeschlagen von bluebyte
Hatte keinen Effekt. Wobei ich noch verwundert bin, dass ProperTree die kexts nicht korrekt sortieren soll. Laut GitHub-Beschreibung gehört die Sortierung zu den Kerneigenschaften von ProperTree:
What does OC Snapshot do?
[...] It will add or remove entries as needed, and also ensures kext load order by comparing each kext's CFBundleIdentifier to all other kexts' OSBundleLibraries within their Info.plist - making sure that any kext that is relied on by others is loaded before them. [...]
LayoutID korrigieren - vorgeschlagen von Bob-Schmu
Da war ich mittlerweile betriebsblind, dass ich das nicht mehr gesehen habe. Ich habe die Daten wie im Dortania Guide gelistet angepasst (https://dortania.github.io/Ope…ell.html#deviceproperties) und verschiedene Varianten getestet (siehe die XML-Kommentar) - hat keinen Unterschied gemacht.
Ein NVRAM Reset hatte ebenfalls keinen Effekt.
BiosVideo.efi als zusätzlichen Treiber - vorgeschlagen von schrup21
Ich habe den Treiber ins Driver-Verzeichnis kopiert und in der config.plist eingetragen:
Leider hat sich dadurch nichts verändert.
CSM von Disabled auf Enabled geändert - vorgeschlagen von grt
Das hatte den interessantesten Effekt. Damit wurde die Auflösung des Bootbildschirms von FullHD auf 1024x768 geändert, obwohl in der config.plist FullHD eingetragen war. In der Mitte des Bootvorgangs, als der Fortschrittsbalken beim Apple-Logo bei ca. der Hälfte stand, ist die Auflösung dann mit einem kurzen Flackern auf FullHD umgesprungen.
Das Verhalten war ähnlich zu Angabe von UEFI -> Output -> Resolution = 1024x768. Tatsächlich war jedoch 1920x1080 eingetragen.
Die bislang beste Variante ist unter UEFI -> Output -> Resolution = 1024x768 anzugeben. Alternativ ist es möglich CSM zu aktivieren, was einen ähnlichen Effekt hat. FullHD über den gesamten Bootvorgang funktioniert mit diesen beiden Varianten aber nicht.
Falls noch jemand eine Idee hat freue ich mich darüber. Anderfalls wird es 1024x768.
Danke & Grüße!
Vielen Dank für die ganzen Rückmeldungen!
Das Git-Repository von lehoa1806 war sogar mein Einstieg. Das Graphikproblem konnte ich damit leider nicht lösen. lehoa1806 lässt die Log-Meldungen durchlaufen ohne GUI.
Die Reihenfolge der kext legt Propertree so bei jedem "OC clean shapshot" fest. Da habe ich mich drauf verlassen, dass es stimmt. Ich versuch es nochmal manuell umzustellen.
Ich komme vermutlich erst nächstes Wochenende zum Testen und werde dann hier Rückmeldung geben, ob sich etwas veränder hat.
Danke!
Liebe Forenmitglieder,
ich stehe kurz vor einer sehr brauchbaren macOS-Installation auf meinem Notebook. Allerdings gibt es noch ein letztes ärgerliches Problem:
Nach dem Booten treten starke Grafik-Artefakte auf (siehe angehängtes Bild), die jedoch verschwinden, sobald ich den Rechner in den Ruhezustand versetze und wieder aufwecke. Diese Artefakte treten außerdem nicht auf, wenn im UEFI unter Output → Resolution die Auflösung auf 1024×768 eingestellt wird.
Soweit die kurze Zusammenfassung des Problems. Hier nun die Details meines Systems:
OpenCore 1.0.2
macOS Big Sur 11.7.10
Notebook: Asus UX305FA
CPU: Intel Core M-5Y10 (Broadwell)
iGPU: Intel HD 5300 (Broadwell)
FullHD-Display (1920×1080)
SMBIOS: MacBook8,1 (nutzt exakt diese CPU)
Ich habe meine komplette config.plist angehängt, allerdings dürften vor allem zwei Abschnitte besonders interessant sein – meiner Meinung nach:
DeviceProperties -> Add
Die obigen Einstellung habe ich entsprechend des Dortania OpenCore guide übernommen.
https://dortania.github.io/Ope…ell.html#deviceproperties
https://dortania.github.io/GPU…l-gpu.html#broadwell-5xxx
UEFI -> Output
Wie man anhand der Kommentare im XML-Code sehen kann, habe ich verschiedene Einstellungen ausprobiert – leider ohne jegliche Wirkung. Nur das Setzen der Auflösung auf 1024×768 behebt das Problem. Das sorgt allerdings dafür, dass der OpenCore-Bootscreen völlig verzerrt aussieht: Das Seitenverhältnis passt nicht mehr und alle Symbole sind viel zu groß.
Ich habe keine Idee mehr, wo ich noch ansetzen oder weiter nachlesen könnte. Die Einstellungen sind gemäß dem Dortania-Guide vorgenommen, und da der Bildschirm nach dem Ruhezustand (oder mit einer Auflösung von 1024×768) fehlerfrei funktioniert, sollten die Kexts und SSDTs eigentlich in Ordnung sein. Mein Verdacht wäre, dass es an irgendeiner Einstellung in der config.plist liegt – aber ich habe keine Idee, welche es sein könnte.
Für jeden Tipp oder Hinweis bin ich sehr dankbar!
Vielen Dank fürs Lesen!
