Beiträge von griven

Grundsätzlich richtig das VoodooHDA unfug ist aber dennoch das es nichts mit dem Thema Audio via HDMI zu tun hat sitmmt so auch nicht so ganz. Der VoodooHDA realisiert nämlich durchaus auch Audio via HDMI/DP ich kann mich noch gut an die alten Zeiten erinnern wo es nötig war genau das zu unterdrücken weil VodooHDA anderfalls nämlich die Ausgabe nur über HDMI gemacht hat und den onBoard Codec links hat liegen lassen Richtig ist aber auch heute muss eigentlich niemand mehr mit VoodooHDA rumwerkeln schon erst recht nicht für Audio via HDMI/DP das geht mit Bordmitteln und dazu braucht es nichtmal AppleALC und/oder AppleHDA. Der analoge onboard Codec (ALC über AppleHDA/AppleALC) und digitiales Audio über HDMI/DP sind zwei komplett unterschieliche Dinge die rein gar nichts miteinander zu tun haben. Das VoodooHDA hier in die Bresche springt hat einzig und allein damit zu tun das dieser Kext das gesamte Audiosystem von macOS komplett umgeht und einen eigenen Treiber für sowohl analoges als auch digitales Audio implementiert...

Moin die DW1560 benötigt meines Wissens nach den Firmware Upload mittels BRCMPatchRam3.kext und BRCMFirmwareData.kext beide werden aber laut den Screenshots des TE nicht geladen von daher kein Wunder das das nicht geht. Einfach mal beide Kexts zusammen mit dem BlueTollFixup.kext aktivieren und dann sollte eigentlich, passendes USB Portmapping vorausgesetzt, BT auch laufen.

Nur mal so am Rand das UEFI Audio Device hat nichts mit dem Sound über HDMI/DP zu tun und kann an der Stelle komplett ignoriert werden (ist nur wichtig wenn man mit OC den Bong beim Systemstart realisieren möchte). Für HDMI/DP Audio braucht es das hda-gfx property an der Grafikkarte oder alternativ im ACPI und darüber hinaus eigentlich nichts. Sofern Du für Deine AMD RX 6600XT Device Properties im Einsatz hast stell sicher das der Key hda-gfx mit dem String Value onboard-1 in den Properties vorhanden ist dann sollte Audio über DP/HDMI eigentlich funktionieren.

Wegen der Verbotsschilder Klamotte da wäre es evtl. auch ne Idee den CustomSMBIOSGuid Patch zu setzen und unter Platforminfo den UpdateSMBIOSMode auf Custom zu stellen? Das Verbotsschild lässt ja in der Regel auf irgendwelche Mäkeleien mit dem SMBIOS schließen und ggf. ist das bei dem Board ja so das sich das SMBIOS nicht ersetzen lässt (wie bei einigen HP`s und Dell`s) ?!

Sowat kommt halt dabei rum wenn man der KI einfach mal so glaubt

Das Kürzel SSDT steht im ACPI Kontext für Secondary System Description Table. Sie sind genau wie die DSDT (Differentiated System Description Table) ein Teil des ACPI und dienen dazu in der DSDT definierte Geräte näher zu beschreiben wobei hier insbesondere der Aspekt der Übersichtlichkeit und Wartbarkeit der Firmware im Vordergrund steht. Es ist halt auf der Seite der Hersteller um einiges einfacher kleine, spezialisierte Blöcke (SSDT's) an unterschiedliche Gegebenheiten anzupassen bzw. zu warten als für jede unterschiedliche Hardware Revision jeweils eigene, komplette DSDT's zu erstellen und zu pflegen.

Ein Kreuz in der IT ist aber auch das Kürzel gerne auch unterschiedliche Bedeutungen haben können und man schnell mal auf dem buchstäblichen Holzweg ist wenn man etwas ohne seinen Kontext betrachtet (in dem Fall ACPI)

Na wenn der Monchi_87 erscheint dann muss ich ja auch erscheinen weil da war ja noch was und so

Den eigentlich entscheidenden Hinweis hat grt in Post #6 gegeben...

Das Problem/die Artefakte liegen an der Art und Weise wie der GOP Treiber (UEFI Mode) die iGPU initialisiert. Das Problem ist ein altes und durchaus bekanntes Problem und tritt fast nur bei Laptops auf. Die "Tricks" gegen das Problem liegen entweder in dem von grt beschriebenen aktivieren des CSM Modes (was das initialisieren des UEFI GOP unterdrückt und macOS erlaubt die iGPU sauber zu initialisieren) oder in der Wahl einer anderen als der nativen Auflösung für die Bios/Preboot Phase was dann einen Modewechsel beim initialisieren des Grafiktreibers von macOS zur Folge hat mit einem vergleichbaren Ergebnis wie dem aktivieren des CSM Modes (gleiches passiert beim Sleep/Wake Zyklus von macOS was dann auch zu einer sauberen Ausgabe führt).

Hier liegt bluebyte vollkommen richtig. Alle M-Serie Mac's haben unified Memory welcher direkt mit auf dem SoC sitzt. Ein einfaches Aufrüsten im Sinne von DIMM Module tauschen/hinzufügen ist hier nicht.

Die beiden schwarzen Bausteine auf dem Bild sind der RAM. Ein wenig irreführend ist der Titel des Videos denn der dort gezeigte Mini ist ein Macmini 8.1 aus dem Jahr 2018 welcher bis zum erscheinen des M1 MacMini ende 2020 verkauft wurde

Wie oben schon erwähnt die OWC Aura passt und ist speziell dafür gemacht

bluebyte ich hab am Elitebook auch nur eine NVME verbaut die sich Win11 und macOS (Sequoia und Tahoe) teilen hier gibt es mit dem Boot von Win11 über OC allerdings keine Probleme (mit ausnahme des weiter vorne schon erwähnten Bios Settings das beim Windows Start via OC nicht aktiv sein darf). Spezielle Einstellungen habe ich nicht vorgenommen im Gegenteil ich habe hier mehr oder weniger einfach die von OpCoreSimplify erzeugte EFI übernommen und nur geringfügig angepasst.

Nee beim early 2013 funktioniert das so tatsächlich nicht

Bei diesen Modellen kommst Du nicht mit einer Adapter Lösung hin sondern musst ein Modul kaufen das direkt passt (OWC Aura Pro zum Beispiel hier: https://www.proshop.de/SSD/OWC…dJhPyxifO0tfyHHUfU3cAAR5h). Der Hintergrund dafür ist das die early 2013 Modelle kein NVME unterstützen sondern nur SATA und auch keinen Anschluss verwenden der direkt auf dem MB sitzt sondern die SSD in ein eigenes "Gehäuse" verbaut haben innerhalb des Rechners.

Ist ein Mid 2015 und frisst SATA M.2 oder M.2 NVME SSD's

Wichtig an der Stelle zu wissen ist das das MacBook einen properitären Anschluss hat sprich Du kannst nicht einfach eine beliebige NVME verwenden da diese nicht passt. Entweder verwendest Du wie von artmusic erwähnt eine SSD von Kingspec (habe ich auch in einem Mid 2015 verbaut und ist okay) die dann direkt mit dem korrekten Anschluss ausgestattet ist oder Du kaufst Dir einen Adapter (https://www.sintech-shop.de/m-…13-2015-jahr-imac/a-10813 als Beispiel) und verwendest dann eine M.2 NVME nach Geschmack

Wirkt sie sich aber nicht Arkturus

Wie ich ja oben schon versucht habe zu erklären sorgt die Methode _STA in der SSDT dafür das deren Code nur dann ausgeführt wird wenn sich das OS als Darwin identifiziert. Die _STA Methode wird immer als erstes ausgeführt und definiert durch die dort enthaltene _OSI Weiche das dieses Device nur dann im ACPI Gerätebaum erscheint wenn das OS Darwin ist (Return 0X0F) und in allen anderen Fällen eben nicht (Return ZERO). Anders ausgedrückt die _INI Methode auf das Geräte wir nur ausgeführt wenn Darwin bootet andernfalls passiert einfach gar nichts und der Rechner verhält sich exakt so wie im dessen originalen ACPI definiert.

Sieht soweit erstmal gut aus bzw. sehe ich nichts was auffällig wäre. Du kannst jetzt Testweise mal die SSDT-XOSI und den dazu gehörenden Patch/Rename deaktivieren und gucken ob das was ändert (ich bezweifle das zwar aber man weiß ja nie).

Die kann es aber eigentlich nicht sein denn laut M$ bezieht sich der Fehlercode explizit auf die _PWR Methode und die kommt in der SSDT ja gar nicht vor. Deine SSDT zu deaktivierung der NVIDIA macht grob das folgende:

• Device (DGPU) -> es wird ein logisches ACPI Device mit dem Namen DGPU erzeugt
• Method (_STA,-> dem erzeugten Device wird eine Status Methode hinzugefügt (wird als erstes verarbeitet) die mittels _OSI Weiche entscheidet on das Device existiert ( Return 0x0F) oder nicht ( Return ZERO)
• Für den Fall das sich das System als Darwin (MacOS) identifiziert gibt _STA 0x0F zurück das Device wird im ACPI Gerätebaum sichtbar und kann vom OS angesteuert werden für alle anderen Fälle gibt _STA Zero zurück und der Rest des Codes wird ignoriert. Wenn Darwin, dann folgt als nächstes Method (_INI und hier ist nur ein einziger Sprung definiert nämlich der zu Method (_OFF,. Das Gerät wird also direkt bei der Initialisierung (Method (_INI) abgeschaltet

Windows meckert hier aber über einen Fehler in einer der _PWR Methoden. Schau mal alle SSDT's durch die Du im Einsatz hast ob das irgendwo ein _PWR definiert ist und guck Dir auch mal an was unter ACPI->Patch so passiert ggf. gibt es auch hier irgendein Rename oder was in die Richtung das da möglicherweise problematisch ist...

Grundvoraussetzung für iGPU: Intel CPU mit maximal UHD 630 iGPU

Maximal von macOS unterstützte AMD Serie: NAVI 21 = RX6900XT (siehe hier: https://dortania.github.io/GPU…-gpu.html#native-amd-gpus )

NVIDIA GPU leider nein, leider gar nicht (zumindest nicht für Deinen usecase so paar olle Kepler basierte gehen mit Kniffen noch)

Insgesamt ist Dein Vorhaben zwar umsetzbar (also DUAL GPU) aber ob das so sinnvoll ist sei dahingestellt. Zum einen frisst ja die jeweils nicht genutzte GPU trotzdem Strom und benötigt die entsprechenden Anschlüsse (Netzteil entsprechend dimensionieren und auch an die Kühlung denken weil Abwärme erzeugt die auch) und zum anderen wird es vermutlich auch nicht reichen die AMD einfach zusätzlich einzubauen und rennt dann schon mit anderen Worten Du wirst Dir ggf. auch Gedanken dazu machen müssen wie Du die NVIDIA unter macOS abschaltest und verbirgst so, das macOS sie gar nicht erst zu Gesicht bekommt (ACPI Bastelspaß garantiert). Meiner Meinung nach wird man hier mit spitzem Stift rechnen müssen ob der nötige Aufwand (sowohl finanziell als auch in Zeit) das zu erwartenden Ergebnis rechtfertig oder ob es nicht am Ende doch mehr Sinn macht ggf. noch ein paar Euro zusätzlich zu investieren und lieber einen (kleinen) M-Serie Mac zu kaufen.

bluebyte zu dem Fehlercode auf Deinen Bild sagt M$ folgendes:

Kontrollier also mal Deine ACPI Dateien und ggf. auch Patches auf Dingen die eine _PWR Methode enthalten und/oder verändern und schau das da überall zwei Elemente drin sind (ggf. die Methode testweise einfach mal entfernen fall nötig oder sauber mit _OSI Weichen nur für Darwin implementieren)...

Ich hatte am Elitebook ganz ähnliche Probleme mit dem Win11 Boot über OC. Am langen Ende war es eine Bios Einstellung die das Problem "behoben" hat. Wenn ich Windows am Elite über OC booten möchte dann darf im Bios VT-x nicht aktiviert sein vielleicht ist ja hier der Fall ganz ähnlich gelagert? Mir hat das auch einige graue Haare beschert...

In den meißten Fällen braucht es zunächst mal ein gehacktes Bios/UEFI damit man damit überhaupt was anderes als ChromeOS laufen lassen kann und dann bleibt die Frage nach der Hardware Ausstattung. Viele Chromebooks/Chromedesks sind lowest End was Hardware angeht oder gleich ARM in beiden Fällen wird das mit macOS schwierig werden weil läuft dann entweder wie ein Sack Nüsse oder eben auch gar nicht je nachdem...

Bestimmt aber ein lustiges Versuchs/Bastelprojekt eben immer abhängig davon was in der Kiste drinnen steckt *gg*

Bluetooth bindet üblicherweise über USB an daher schau im Gerätemanger mal bei den USB Geräten da wirst Du dann wohl fündig werden.