Beiträge von griven

Sehe ich auch so und mag daher erneut darum bitten künftig solche Dinge einfach zu unterlassen. Beschränkt Euch doch bitte einfach auf den technischen Diskurs und bewertet nicht evtl. von einem TE gesetzte Links zumindest nicht solange sie nicht auf offensichtlich illegales verlinken oder ausschließlich die Intention verfolgen bestimmte Meinungen und/oder Produkte zu propagieren. Ich danke Euch.

Hast Du nachdem Du das iPhone aus dem Backup wiederhergestellt hast geprüft ob iMessage in iCloud auf dem Gerät aktiviert ist? Falls nicht bitte mal wie folgt checken:

1. Einstellungen öffnen

2. Auf den Namen des iCloud Accounts tippen (AppleID)

3. Auf iCloud tippen

4. Auf alle anzeigen gehen und dann Nachrichten aktivieren falls nicht schon aktiv

Die Nachrichten syncen dann automatisch mit dem Stand aus der iCloud. Soweit ich weiß sind die Nachrichten bei aktivierter iMessage in iCloud Funktion nämlich nicht Teil des eigentlichen Gerätebackups was auch erklärt warum ein Restore den Verlauf nicht zurückgebracht hat. Vorteil davon das sie nicht Teil des allgemeinen Backups sind ist aber auch das die Chance darauf den kompletten Verlauf (inkl. der fehlenden Tage) zurück zu bekommen weil der Sync der Nachrichte in die Cloud unabhängig vom Backup ständig abläuft

Mal unabhängig davon ob die Frage nach einem APK in einem Hackintosh Forum, zumal im Android Bereich platziert, passend ist oder nicht verstehe ich nicht warum Ihr Euch über den Link den der TE gesetzt hat so echauffiert bzw. frage mich ob Ihr Euch auch so echauffieren würdet wenn es nicht um Bluesky sondern um X vormals Twitter ginge? Der dort angezeigte Feed ist doch einfach nur der Standardfeed von Bluesky wie ihn jeder zu Gesicht bekommt der in dem Netzwerk noch nicht angemeldet ist. Natürlich lässt sich über die Qualität dessen was der Feed zeigt streiten aber das ist ja nun etwas das generell auf Social Media Apps anzuwenden wäre oder liege ich da falsch? Ich finde hier sollte man die Kirche im Dorf lassen denn, ob uns das nun passt oder nicht, Social Media ist in all seinen bunten Varianten inzwischen leider ein Teil unser aller Realität 🤷

martin#001 das Rog Ally Z1 ist ein Handheld Device vergleichbar mit einem Steamdeck oder so da bauste keine andere Grafikkarte ein. Das Ding ist zum daddeln gedacht und für sonst nix

Naja disk3s3 ist ja gerade mal 839,7KB groß (also nicht mal 1 MegaByte) wie soll das also funktionieren? Denke Du hast da beim erstellen des Containers was falsch gemacht ich denke das sinnvollste wäre es den Container nochmal zu löschen und neu zu erstellen

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...